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ABSTRACT 


The  Naval  Postgraduate  School  has  been  conducting  research  into  Uie  deogn 
and  testing  of  an  Autonomous  Underwater  V^de.  One  facet  of  this  researdi  is  to 
incrflin«ntally  design  a  software  architecture  and  implement  it  in  an  advanced 
testhed,  the  AUV  n.  As  part  of  the  hi^  level  ardutecture.  a  Mission  Executor  is 
being  constructed  noing  NASA’s  CLIPS  version  5.0.  ^e  Misaon  ESxecutor  is  an 
expert  system  designed  to  oversee  progress  ftom  the  AUV  launch  point  to  a  goal  area 
and  back  to  the  origin.  It  is  e]q>ected  that  the  Executor  will  make  informed  decisions 
about  the  mission,  taking  into  account  the  navigational  path,  the  vehide  subsystems 
health,  and  the  sea  environment,  as  wdl  as  the  specific  mission  profile  which  is 
downloaded  fiom  an  ofiboard  mission  planner.  Heuristics  for  maneuvering, 
avoidance  of  uncharted  obstades,  waypoint  navigation,  and  reaction  to  emergendes 
(essentially  the  expert  knowledge  ofa  submarine  captain)  are  required.  TheMiasion 
Executor  prototype,  SKIPPER,  attempts  to  do  this  throu^  the  use  of  a  three-tiered 
reasoning  system  which  monitors  overall  mission  status,  functional  area  status,  and 
vehide  equijnnent  status  simultaneously. 
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L  INTRODUCTION 


A.  BACKGROUND 

The  development  of  autonomous  underwater  vehicles  has  been  an  ambitkm  for 
decades.  Only  recently,  however,  have  practical  autonomous  underwater  vehicles  tq>peaied 
to  be  reality.  Since  the  develqnnent  of  SPURV I  (one  of  the  first  auttXKMnous  underwater 
vehicles  in  the  United  States)  at  the  University  of  Washington’s  Applied  niysics 
Laboratcxy  in  1963,  government  and  civil  interest  has  been  fueled  by  the  potential  for 
many  applications  (Busby  90,  p.  65).  The  hope  is  that  the  control  system  for  the  vehicle 
will  adequately  perform  the  man-machine  interaction  that  regularly  takes  place  on  manned 
submersibles.  Military  interest  over  die  last  decade  has  increased,  particularly  with  the 
advent  of  tactical  automated  weiqxms  and  air  rectninaissance  vehicles.  Recent  events  in 
the  Gulf  War  have  validated  the  advances  in  automated  wetqwns  during  die  1980’ s.  As 
Vice  Admiral  Stanley  Arthur,  Commander  U.  S.  Naval  Forces  Central  Cmnmand  during 
Operation  Desert  Storm,  remarked  (on  Tomahawk  cruise  missile  system  effectiveness): 

...  tatget-anival  percentages  look  good.  When  dealing  with  a  system  such  as 
Tomahawk,  ail  the  details  can  be  planned  carefully.  Then  when  the  missile  is  fired, 
the  electronic  gizmos  take  over.  These  integrated  circuits  do  not  get  scared;  they  do 
not  forget;  they  follow  orders  well.  The  critics-who  said  Tonuduiwk  wtMdd  work 
only  (HI  a  sin^e  test  range  and  that  it  w(Miid  get  lost  in  the  (tesert-were  wrong. 
News  repcHts  seem  to  supptnt  the  idea  that  attacks  by  robots  have  a  unique 
psychological  effect  (Hi  pe(^le.  (Arthur,  1991,  pp.  85-86) 


On  the  effectiveness  of  the  remotely  piloted  vehicle.  Pioneer  I,  Vice  Admiral  Arthur 
also  observed: 

RemtMely  piloted  vehicles  proved  to  be  marvelous,  versatile  devices.  They  allowed 
the  battleships  to  attack  the  enemy  on  their  own,  without  the  need  for  outside 
assistance  in  spotting.  Spotting  by  the  RPV‘s  not  only  allowed  for  accurate  naval 
gunfire  support,  but  also  provided  instant  battle  damage  assessment  The  RPV 
offers  quick  response  and  flexibility,  because  it  is  under  positive  tactical  control  and 
has  the  ability  to  get  below  a  low  ceiling.  Of  course,  ihe  highlight  of  the  war  for 
the  RPV  has  to  be  the  incident  in  which  a  remotely  piloted  vehicle  flew  over  Iraqi 
troops.  By  that  time,  the  Iraqis  knew  what  would  be  coming  next,  so  they 
sunendeted  to  the  RPV->piesumably  the  first  occasion  in  the  history  of  warfare  for 
human  beings  to  capitulate  to  a  rotot.  (Arthur  1991,  p.  86) 

Several  marine  autonomous  and  remotely-piloted  vehicles  are  already  in  use  for 
such  diverse  functions  as  underwater  cable  inspection,  hydrography,  and  mine-hunting. 
The  practical  advantage  of  low-risk  to  human  operators  coupled  with  the  potential  ability 
to  operate  at  over-the-horizon  distances  make  the  autonomous  underwater  vehicle  a  highly 
desirable  project.  Although  development  of  autonomous  underwater  vehicles  has 
progressed  more  slowly  than  the  well-publiciad  air  and  land  vehicles,  advances  during 
the  1980’s  in  artificial  intelligence  and  robotics  have  proven  to  be  monumental  As  a 
consequence,  the  Defense  Advanced  Research  Projects  Agency  (DARPA)  has  been  the 
primary  major  funding  source  for  the  evolutionary  advances  made  during  the  last  decade. 
(Polmar,  1991,  pp.  122-123).  Early  research  in  autonomous  underwater  vehicles  at  the 
Naval  Postgraduate  School  centered  around  computer  and  control  surface  interfaces  tested 
in  the  fust  testbed.  Autonomous  Underwater  Vehicle  I  (AUV  I),  a  tele-operated 
underwater  robot  Efforts  since  that  testing  ended  have  focussed  on  an  entirely 
autonomous  vehicle.  Autonomous  Underwarer  Vehicle  11  (AUV  II). 
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Previous  student  theses  at  the  Naval  Postgraduate  School  have  primarily 
concentrated  on  the  use  of  artificial  intelligence  in  mission-planning  and  giiiA»nce  control 
of  the  vehicle.  Qoutier  investigated  and  developed  a  vehicle  Guidance  subsystem.  His 
subsystem  provides  fora  piopo'  vehicle  configuration  for  path  following  from  waypoint 
to  waypoint  (Qoutier  1990).  Ong  researched  and  developed  an  extensive  offboard 
Missitm  Piaruiing  expert  system.  This  was  incorporated  into  an  advanced  simulator 
developed  previously  (Ong  1990).  MacPherson  studied  rule-based  control  of  an  AUV. 
He  implemented  this  control  system  in  a  simulator  written  in  LISP  under  the  Knowledge 
Engineering  Envircmment  (KEE).  Generic  mission  templates  were  developed  for  various 
specialized  mission  profiles  (MacPherson  1988). 

The  current  generation  of  student  theses  attempts  to  take  tire  development  of  an 
intelligent  control  system  for  the  AUV  into  the  next  increment  of  evolution.  The  baseline 
diagram  of  the  projected  software  system  is  depicted  in  Figure  1*1.  Both  intermediate 
level  modules  (such  as  the  pattern  recogniticm  and  navigation  software)  and  high-level 
mothiles  such  as  the  mission  plannerAeplanner  and  mission  executor  are  now  in 
development  Central  to  the  high-level  control  is  the  Mission  Executor  described  in  the 
next  section.  An  advanced  decisionmaking  capability  is  needed  to  make  an  autonomous 
underwater  vehicle  (AUV)  truly  adi^tive  and  survivable.  The  noted  naval  analyst 
Norman  Polmar  recently  surveyed  the  current  advances  and  underscored  the  demand  for 
intelligent  aqrability  in  vehicle  technologies  : 
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The  key  to  success  in  all  die  testing  will  be  component  or  "enabling”  techndogies: 
navigation,  composite  hull  materials,  guidance,  energy  source,  propulsitm, 
communicatitm  links,  and  signal  processing  as  well  as  the  qiecific  mission 
packa^.  Advanced  auttmommis  underwata*  vehicles  will  require  enhanced  smisor 
and  decisitm-maldng  capabili^.  (Polmar  1991,  p.  123) 

B.  MISSION  EXECUTION  EXPERT  SYSTEM 

The  control  architecture  oi  AUV  n  has  undergtme  several  phases  of  develqimmiL 
Many  methods  of  autonomous  control  are  being  used  in  vehicle  testbeds  around  the 
country.  Some  allow  for  layming  of  control  in  the  vehicle  while  others  maintain  a  more 
traditional  hoiizcMital  model  of  planning,  execution  and  analysis.  One  general  architecture 
that  has  recently  come  of  age  is  topHlown  flow  of  control  ranging  from  Strategic  level 
control  throng  tactical  level  to  the  low-level  monitoring  level  (the  level  at  which  vehicle 
software  and  hardware  actually  interface).  Higher  levels  of  abstracticm  perform  some  of 
the  activities  (some  time-sensitive)  which  require  measured  decision-making. 

The  Naval  Postgraduate  School’s  AUV  control  structure  has  undergone  an 
evolutionary  development  Control  in  AUV  I  and  early  control  structures  in  AUV  n  was 
essentially  low  level  closed-loop.  Incremental  changes  to  the  software  design  in  1990 
necessitated  the  integration  of  a  Missicm  Executor  to  integrate  and  cotndinate  intelligent 
waypoint  following  and  obstacle-avoidance.  The  Mission  Executor  functicms  involve 
continwHis  real-time  aiudysis  and  high-level  supervision  of  vehicle  systems  throu^iout 
the  life  of  a  mission.  Thus  tiie  Executor  must  make  real-time  decisions,  often  in  an 
miviromnmit  of  uncertainty  or  incomplete  knowledge  (Healy  1990a,  pp.  177-183).  While 
not  all  situations  can  be  completely  provided  for  in  tiie  system,  tiie  ambition  is  to  design 


heuristics  which  make  it  possible  for  die  Executor  to  deal  with  exiensioiis  of  well-known 
problmns. 

C.  SCOPE  OF  THESIS 

The  Mission  Executor,  in  the  broadest  sense,  must  be  able  to  safely  contnd 
movement  between  a  mission  starting  point  and  a  missi<m  goal  In  doing  so.  it  must 
operate  between  three  models:  duu  oi  die  mission  world,  die  vehicte  world  and  the 
environmental  world.  To  supervise  die  vehicle  world  suggests  that  die  Executor  must 
monitor  and  contrtd  vehicle  liealdi"  such  as  battery  state,  internal  system  pressure,  and 
temperature.  It  must  also  provide  for  response  to  deteriorating  condidcm  of  die  vehicle 
sonar,  navigation  system,  or  guidance  systems.  The  loss  of  a  major  onboard  equipment 
such  as  the  sonar  or  navigation  systems  wmild  probably  be  catastrophic  and  would  at  least 
result  in  a  mission  degradation.  The  Executor  must  supervise  the  subsystem  recovery 
procedure  or  make  decisions  that  can  circumvent  the  problem.  Failing  dut  it  must  make 
a  strategic-level  decision  to  abort  the  mission. 

Control  of  the  vehicle  in  die  context  of  die  environmental  world  means  reaction  to 
topological  features  such  as  undersea  terrain  and  obstacles  (both  moving  and  non¬ 
moving),  a  significant  change  in  atmospheric  conditions,  or  any  external  threat  udiich 
would  physically  hinder  the  vehicle  from  making  the  transit  to  the  goal  point 

Moniiaring  of  the  mission  woild  entails  awareness  of  transition  points  between 
normal  transit  and  beginning  a  special  minion  {uofile.  Possible  qieedAlepth  dianges, 
special  requiiements  for  inshore  navigation,  and  dqiloyment  of  any  equqiment  must  be 


considered.  Most  importandy.  the  mission  priority  must  be  iwiiitiffwrf  against  vehicle 
survival  and  reusability.  Heuristics  for  dus  must  be  incoporated  in  the  software. 

D.  THESIS  ORGANIZATION 

Cluqjter  II  is  a  survey  of  previous  work  on  AUV  control  systems  and  related 
technology.  Current  AUV  software  omtiol  systems  at  many  different  research  facilities 
are  discussed.  AUV  research  is  classified  by  die  types  of  software  architecture. 

Charter  in  is  a  feasibility  study  of  using  the  C  Language  Integrated  Producdon 
System  (CUPS)  versicm  S.O  expert  system  tool  as  the  development  envirtmment  for  die 
Mission  Executor.  This  chapter  also  includes  analysis  of  the  portability  of  CLIPS  to 
GESPAC  the  AUV  U’s  onboard  computer. 

Chapter  IV  is  a  description  of  miboard  informadon  processing.  It  details  die 
interactions  between  various  modules  of  the  software  architecture  outlined  in  the  baseline 
diagram.  Figure  1-1. 

Chapter  V  is  a  description  of  the  ptmotype  expert  system  architecture  from  a 
thetnetical  stance.  The  development  of  layers  of  teasmiing  in  software  is  highlighted. 
Issues  such  as  the  proper  combination  of  rules  and  objects,  the  role  of  uncertainty  and 
truth  maintenance,  and  knowledge-database  objea  persistence  are  discussed  in  the  context 
of  the  Autonomous  Underwater  Vehicle.  Specific  software  consuructs  are  left  to  Quyita’ 
VI. 
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OuqMer  VI  is  a  descrqition  of  both  the  Mission  Executor  constructs  and  the 
Executor  siniulation.  Rules  which  incocponte  some  special  complexity  or  feature  are 
described  in  detail. 

CluqitBr  Vn  outlines  contributions,  ctmclusions  and  extensims  for  fuidier  woik. 
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E.  CONTROL  FOR  AUTONOMOUS  UNDERWATER  VEHICLES 

This  cluq)ter  is  an  overview  of  Autonomous  Vehicle  high-level  contnd 
development  at  other  institutions  and  cmnmeicial  organizatimis.  The  various  autonomous 
vehicle  programs  ate  classified  by  software  architecture.  Differences  and  sitnilarities  to 
die  Naval  Postgraduate  School’s  testbed  AUV  n  are  discussed  in  the  concluding 
summary. 

A.  LAYERED  CONTROL  ARCHITECTURE 

1.  Massachusetts  Institute  of  Technology  Sea  Grant  Program 

Bellingham  and  Consi  of  the  Massachusetts  Institute  of  Technology  have  been 
at  the  fotefiont  ai  AUV  research  for  the  last  several  years.  The  MTT  program  has  woriced 
with  Charies  Stark  Drqier  Laboratories  and  Intematicmal  Submarine  Engineering  cm  the 
development  cf  Sea  Squirt  I  (Bellingham  1$190,  p.  23).  This  platform  uses  a  Motorola 
68020  processor.  MIT  Sea  Grant  is  implementing  a  software  architecture  based  on 
Brook’s  layered  contrcd  architecture  (Brooks  1986,  pp.  36S-372).  This  architecture  is 
bdutviar>osienied,  using  the  subsumption  qrproach.  The  objective  is  to  move  away  fiom 
the  traditional  robot  architectures  which  require  a  world  model  be  incorporated.  This  is 
due  to  die  AUV  compaction  problem:  a  small  submersible  cannot  support  high-resolution 
sonar  or  an  extensive,  intelligent  vision  syston.  Consi  and  Bellingham  argue  that  die 
world  model  is  dien  severely  flawed,  which  may  lead  to  incorrect  or  conflicting  behaviors 
(Bellingham  1990,  pp.  23-24).  Li  the  sulmomptkin  model,  hi^-level  behavion  include 
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planning  and  monitoring  while  lower  level  behaviors  are  oriented  toward  die  reflexive 
states.  The  strfiware  develqmient  itself  is  intriguing.  Low-onJo*  behaviors  are  first 
installed  and  verified  in  die  tesdied.  When  sadsfactoiy  performance  is  achieved,  die  next 
level  of  complex  behavion  is  dien  added.  Abstracdy,  the  lower  level  is  subsumed  by  die 
higher  level,  but  nonetheless  carries  out  its  behaviors  in  real-time.  The  architecture  is 
designed  to  be  reconfigurable  for  different  missions.  (Bellinj^iam  1990,  pp.  24,27) 

Despite  an  initial  retreat  from  die  worid  model  paradigm,  die  MIT  group 
believes  it  might  be  useful  in  complex  missions  to  incorporate  worid  modeling  into  high 
layers.  This  would  free  lower  levels  to  ctmtinue  to  operate  in  real-time  as  diey  must 
The  overall  architectute  will  become  distributed  for  sensor  processing.  (Bellin^iam  1990a, 
pp.  75-78)  A  diagram  d  the  basic  behavior  layoing  is  shown  in  Figure  2-1. 

2.  Iirtematfonnl  Submarine  Enginceriiig  (ISE) 

International  Submarine  Engin^ring  (ISE)  is  cunendy  cooperating  widi  MIT 
on  the  Sea  Squin  research.  International  Submarine  has  previously  developed  several 
software  architectures  for  its  series  of  ARCS  underwater  vehicles  (Zheng  1990,  p.  71). 
Origitud  work  focussed  on  a  software  archit«;ture  based  on  the  Navy  watch  team  concept 
d  functionality.  Control  was  based  on  die  Cooperating  Experts  Paradigm,  in  which 
squme  modules  for  piloting,  independent  transit  and  collision  avoidance  all  worked  to 
form  a  fused  plan.  After  much  experimentadon,  this  was  discarded  as  infeasible  because 
module  functionality  did  not  always  cocreqxmd  well  to  the  many  tasks  that  even  one 
human  carried  out  Furdier  decomporidon  was  necessary. 
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Figure  2-1.  MIT’s  Layered  Control  Architecture 


ISE’s  new  architecture  is  object-oriented  and  behavior-oriented,  based  upon 
Brodc’s  seminal  layered  control  architecture  of  the  mid-1980’s.  ISE  incorporates  rule- 
based  heuristics  and  learning  through  reflexive  behaviors,  logical  behaviors  and  learned 
behaviors. 

X  The  Analytic  Sdences  Corp(M:ation/  Naval  Underwater 
Systems  Center 

The  Analytic  Sciences  CotpoFaticm  (TASC)  and  die  Naval  Underwater  Systems 
Center  (NUSQ  have  developed  a  novel  software  architecture  which  combines  aspects  of 
real-time  layering,  functkmal  decompositicm  and  subsumption.  It  is  a  new  structuring  of 
die  traditional  perception,  arudysis  and  action  paradigm  of  robotic  software.  The  software 
architecture  is  being  implemented  in  C-t-t-.  (Schudy  1990,  p.  9) 

Unlike  die  division  of  functions  in  the  Intelligent  Mobile  Autonomous  System 
(IMAS)  in  which  each  level  carries  a  similar  structure  for  conflict-resolver,  world  model 
and  level-specific  function,  the  division  of  tasks  in  the  NUSC/TASC  architecture  is  non- 
homogeneous  both  horizontally  and  vertically.  It  is  divided  horizontally  into  an  amdysis 
hierarchy  which  is  composed  vertically  of  increasingly  competent  levels  of  assessment 
The  bottom  level  is  real-time  while  the  event  assessment  at  die  highest  level  is  decidedly 
non-real-time.  This  hioarchy  at  each  level  functions  as  effectors  for  the  tighdy-ooupled 
planning  and  supervision  sections  the  Task  Decomposition  hierarchy.  The  planning 
section  consists  in  the  levels  of  mission  plaiuiing  (highest),  phase  plaiming,  task  planning, 
and  action  planning  (lowest  level).  The  supervisimi  functional  section  is  divided  into 
mission  level  plan  execution  (highest),  phase  level  plan  execution,  task  execution,  and 
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subsystem  supervision  Oowest).  Positioned  between  the  analysis  and  planning  areas  is 
a  response  system  in  which  responses  are  merged  and  subsumption  of  behaviors  occurs. 
These  hierarchies  are  separated  from  the  low-level  functions  of  sensoiy  data,  internal 
monitoring  and  guidance  control.  (Schudy  1990,  pp.  10-14)  This  is  depicted  in  Figure 
2-2. 

Rather  than  just  consider  the  division  of  function  by  functional  level,  there  is 
also  decomposition  by  time.  Real-time  control  only  encompasses  the  lower  levels, 
mtMiitoring  and  control  in  the  most  atomic  sense  and  the  planning/assessment  that  is  <me 
level  above  duit  The  actual  flow  of  control  is  very  evident  The  advantages  of  such  a 
system  are  that  mission  execution  can  be  monitored  at  a  high  rate  for  low  level  behaviors 
while,  as  in  layered  control,  the  high  level  behaviors  such  as  planning  and  global 
assessment  are  done  at  a  less  time-constrained  rate.  (Schudy  1990,  pp.  13-14) 

Unlilre  the  strict  layered  control  hierarchy,  this  system  maintains  a  detailed 
world  model  which  consists  of  a  vehicle  intmual  model,  an  mivironmental  model,  and  a 
event  assessment  model  Like  the  layered  control  hierarchy,  there  is  subsumption.  Radier 
than  describing  it  in  lenns  of  competent  behaviors,  it  is  described  in  terms  of  assessment 
and  response.  Assessment  modules  describe  bdiavior  in  mathematical  models  (Schudy 
1990,  pp.  14-16).  Response  modules  are  intermediate  to  die  planning  modules  and 
incorporate  behavioral  alternatives. 

Mission  execution  is  carefully  supervised  by  an  overall  mission  execution 
manager,  b  one  sense,  die  overall  mission  execution  maiuiger  is  nothing  more  dian  a 
high-level  sequencer.  The  mission  execution  manager  in  turn  supervises  phase  execution 
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Analysb  Hfenrchy  Tiuk  Decomposition 
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Figure  2>2.  TASCyNUSCAUV  Scrfiware  Architecture 


managers.  Phase  execution  managers  have  responsibility  for  monitoring  an  entire  phase 
of  the  mission.  These  are  intermediate  mission  executors  which  oversee  the  task 
execution  managers.  In  naval  terms,  the  task  execution  manager  can  be  described  as  a 
special  (tetail.  It  is  the  task  execution  manager’s  responsibility  to  ensure  that  a  special 
evolution  such  as  turning  at  a  waypoint  is  carried  out  Furdter,  the  task  execution 
manager  monitors  a  subsystem  manager  for  each  of  the  following  environmental  sensing, 
navigation,  guidance,  amimunication  and  energy.  (Schudy  1990,  pp.  18-20)  This  software 
architecture  is  one  of  the  few  to  specifically  mention  mission  execution  as  a  high-level 
control  activity. 

4.  Marine  Systems  Engineering  Laboratory 

Marine  Systems  Engineering  Laboratury  at  the  University  of  New  Hampshire 
has  been  involved  in  AUV  research  for  over  fourteen  years.  The  first  underwater 
autonomous  vehicle  developed  was  EAVE I  (Experimental  Autonomous  VEhicle  I)  which 
was  completed  in  1978.  It  was  designed  for  cleaning  underwater  pipelines.  In  1986, 
MSEL  was  given  a  charter  to  develq)  knowledge-based  AUV’s  which  could  render 
complex  decisions  and  operate  independently.  (Thus,  the  acronym  for  EAVE  became 
KB/EAVE.)  EAVE  is  a  larger  class  of  AUV  than  the  NPS  AUV  II  (and  similar  small 
AUV’s)  which  is  hardware-intensive;  resident  onboard  are  three  Motorola  68(X)0 
processors  for  die  lower  level  and  VME  68020’s  for  the  higher  level  decision  making. 
Lowest  level  control,  guidance  and  monitoring  functions  are  carried  out  in  the  Iowa*  level 
680(X)  processes.  (Blidberg  1990,  pp.  33-34) 


Although  the  upper  and  lower  levels  of  decision-making  are  coupled,  MSEL 
designed  the  lower  level  to  be  stand-alone  in  the  event  that  strata  independence  was 
necessary.  The  design  of  the  KB/EA VE  software  ^stem  for  the  EAVE  m  generation  of 
vehicles  is  structured  around  data  that  is  transformed  firom  raw  sensory  output  eventually 
to  knowledge  ftH*  complex  decision-making.  This  is  achieved  through  functional  layering. 
Mission  functions  reside  at  the  highest  le>wl  while  control  functions  are  at  the  lowest 
level  This  design  is  not  wholly  hierarchical  in  the  sense  that  each  level  is  divided 
horizontally  into  data  manipulation  on  one  side  and  control  on  the  other.  This  design  is 
depicted  in  Figure  2*3.  The  hierarchical  division  is  based  on  time  constraints.  As  in 
many  of  the  control  architectures,  the  notion  is  to  give  the  planning  and  assessment 
functions  more  time  while  requiring  guidance  and  direction  motion  control  to  operate 
quickly.  (Blidberg  1990,  pp.  35-36) 

The  lowest  level  reads  and  controls  sensors  and  activates  control  surfaces.  In 
the  next  higher  level,  the  system  level  receives  packaged  data  from  tire  lowest  level  and 
generates  intermediate  level  ccmimands.  The  environment  level  (just  above)  perfonns 
navigation  functions  and  planiting  based  on  goals  received  from  the  mission  (highest) 
level  This  level  performs  the  tasking  and  uses  the  state  of  the  vehicle  at  the  environment 
level  to  generate  high-level  plans.  A  philosophy  that  tiie  system  can  artificially  evolve 
has  prompted  MSEL  to  attempt  to  build  and  test  the  lower  level  before  it  proceeds  to  die 
next  highest  level  (Blidberg  1990,  pp.  36-37).  This  is  similar  in  concept  to  construction 
in  Brooks’s  layered  control  architecture. 
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Figure  2-3.  EAV  in  Software  Architecture 
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The  decision-making  software  in  the  higher  levels  uses  what  is  known  as 
schema-based  reasoning  developed  by  Turner  of  the  University  of  New  Hampshire  MSEL 
group.  These  schema  are  essentially  templates  of  reasoning  ami  behavior  which  cover 
such  areas  as  reaction  to  critical  situations,  (tevelopment  and  considoatitm  of  plans  and 
focus  of  attention  (Blidberg  1990,  iq[>.  39-41). 

The  MSEL  KB/EAVE  strftware  devek^ent  also  involves  using  die  Portable 
Common  LISP  Subset  or  PCLS.  The  effort  to  find  a  portable  (Aject-oriented  LISP  subset 
was  based  on  a  need  to  find  a  programming  environment  that  was  indqiendent  of 
hardware  layout  While  the  C  language  is  being  used  for  numerically-intensive  tasks  such 
as  sensor  data  processing  and  guidance  tasks  in  the  two  lower  levels,  intnmediate  and 
high-level  fiincticms  are  targeted  for  develt^ent  in  PCLS.  Part  of  die  world  model 
(navigadcm/situaticxi  assessment  level)  is  abeidy  functioning  in  the  testbed.  PCLS  works 
well  because  it  does  not  have  the  temporal  overhead  usually  associated  with  LISP.  MSEL 
describes  it  as  "garbage  collection  compi^tm.  ”  (Bowen  1990,  pp.  221-226) 

B.  HIERARCHICAL  CONTROL 

1.  Intdligent  Mobile  Autonomous  System  (IMAS) 

Meystel  of  the  Laboratory  of  Aj^lied  Machine  Inrelligence  and  Robotics 
(LAMIR)  of  Drexel  University  and  Isik  of  Syracuse  University  of  have  developed  a 
hierarchical  model  of  control  for  a  terrestrial  robot  vehicle  under  develq[mient  for  the 
Belvmr  Army  Research  and  Development  Engineering  Center  (Isik  1990,  pp.  241-242). 
Aldiou^  diis  involves  a  wheeled  surface  vehicle  with  a  vision  sensor  system,  the  Nest 
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Hierarchical  Oontnd  paradigm  is  iq>plicable  for  subsea  autonomous  robots  with  sound 
ranging  sensors.  It  provides  both  sufficient  redundancy  and  layering  of  automated 
reasoning,  as  the  following  description  and  Figure  2-4  suggest 

The  software  is  divided  hierarchically  into  the  planner,  navigator,  pilot  and 
actuator/controUer  levels.  Each  level  has  its  own  separate  sensor  bank  for  percq>ti(ni,  a 
m^>  for  worid  model  reasoning,  and  a  reporter  for  intelligent  control.  The  functional  unit 
itself  (planner,  navigator,  pilot  and  actuatm/controller)  has  its  own  database,  rulebase  and 
evaluate.  Each  stratum  has  a  different  level  of  resolution  for  its  sensors.  Data  conflicts 
are  resolved  via  what  is  known  as  resolution  relevance.  The  Reporter  module  in  each 
stratum  performs  the  conflict  resolution.  (Isik  1990,  p.  242) 

The  rule  base  is  modeled  as  a  production  system.  Fuzzy  set  theory  is  used  in 
the  controllers  to  describe  relationships  and  control  actions  within  and  outside  of  the 
vehicle.  The  global  view  of  the  environment  via  the  vision  system  is  used  in  the  top  two 
layers  while  the  Pilot  level  uses  a  local  or  "windshield"  view  tt>  guide  the  vehicle  along 
the  planned  path  (Isik  1990,  p.  242-243). 

2.  SINTEF  SACOR  Project 

SINTEF  Auttmiatic  Control  of  Tmxlheim,  Norway  has  developed  several 
robotic  vehicles  over  the  past  several  years.  The  current  vehicle  being  used  is  the 
SPRINT  101,  a  tethered  vehicle.  This  is  a  data-autonomous  vehicle  with  six  sonars  which 
receives  power  via  an  umbilical  cable.  The  software  resides  on  a  68020  processor. 
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SACX>R  is  an  acnmym  for  Software  for  Autonomous  Control  oi  ROV90.  Software  is 
being  developed  in  C-h-  and  currently  resides  on  SUN  wockstatioos  (Rodsedi  1990,  pp. 
15-18). 

SAGOR  is  actually  a  software  design  in  two  parts.  The  administrative  section, 
known  as  ASACS  (Administrative  System  for  AUV  Control  Software),  sequences  and 
controls  the  flow  of  data  in  the  system.  The  scrftware  is  object-oriented.  Modules,  which 
are  abstracted  behind  data  structures,  cannot  communicate  directly.  They  must  pass  data 
dirou^  strict  interfaces.  This  is  principally  the  object-oriented  paradigm.  ASACS  is 
essentially  a  hierarchical  system.  The  database  controller  interfaces  modules  to  state 
variables.  Progress  in  status  is  compared  to  desired  goals.  An  event  handler  generates 
an  object  for  each  event  and  schedules  it  for  tranqxvt  to  the  correct  module.  A 
monitoring  unit  known  as  the  Watchdog  conducts  error  cheddng  of  vehicle  internals  and 
navigational  inogress.  The  Qq>tain  module  is  a  simple  sequencer  for  the  mission  plan. 
The  plan  itself  is  a  hierarchical  structure  of  state  variables  and  conditions  under  which 
they  ate  activated  (Rodseth  1990,  pp.  15-17).  The  dataflow  and  ctmtrol  is  diagrammed 
in  Figure  2-5. 

Modules  ate  eidier  update  or  action  modules.  Action  modules  channel 
commands  from  the  highest  levels  down.  Modules  cm  lower  levels  outweigh  diose  in 
higher  levels.  (Presumably  this  is  because  lower  level  modules  are  real-time  directors  of 
action.)  New  goals  ate  develtqted  through  plan  conflict  tesolotion.  Update  modules 
provide  information  from  sensors  attached  to  actuators  and  may  direct  action  across  a 
ran^  of  state  variables  (Rodsedi  1990,  pp.  18-20).  Rodseth’s  description  ai  die  cutient 
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implementatiofi  indicaies  that  diis  software  is  not  yet  mature.  Navigation  is  conducted 
by  a  dead>reckoning  device  rather  dum  a  combination  ci  dead-reckoning  and  sonar 
comparisons  as  in  the  NFS  AUV  IL  Speed,  heading  and  depth  can  be  controlled.  A 
waypoint  determination  module  allows  for  compuuuitm  of  the  speed  and  heading  to  gain 
the  next  waypcnnL 

It  is  interesting  to  note  that  SINTEF  project  designers  have  noted  for  possible 
future  work  die  development  and  integradon  of  an  intelligent  cq>tain  uriuch  could  reason 
about  decisions  and  an  intelligent  watchdog  for  the  vehicle  internals  (Rodseth  1990,  p. 
23).  This  is  essentially  die  idea  of  a  Mission  Executor  as  oudined  by  the  Naval 
Postgraduate  School. 

C.  HYBRID  MODELS 

L  University  of  Karbnihc  Robot  Project 

Rembold  and  Levi  have  been  directing  research  at  the  Universi^  trf  Karlsruhe, 
Germany  into  die  oonmd  of  autonomous  vehicles  with  die  4-wheeled  MOBILE  ROBOT 
(Rembold  1986,  pp.  79-80).  They  partidon  the  control  modules  into  a  world  processor, 
the  planning  and  execution  processor,  and  sensor  processor.  Radier  than  a  pure  vertical 
or  horizontal  hierarchy.  Ronbdd  and  Levi  describe  their  flow  of  execution  as  a  hybrid 
of  both.  The  real  world  model  and  die  sensor  module  cooperate  in  providing  the 
interpietmion  of  sensory  ooqnit  and  in  staring  die  vehicle  internal  worid.  The  planning 
and  execution  processor  allows  for  comparison  of  a  real-workl  scenario  with  die  current 
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toenario  10  determine  the  action  to  be  given  to  lower  levels  of  guidance  and  comnd.  The 
decision-inaking  firamewok  is  a  hienudiical,  almost  tree-like  rule-based  structure 
(Rembold  1986,  pp.  80-83). 

Levi  and  Rembold  also  require  the  software  contitd  system  to  do  a  limited 
amount  of  learning  and  to  operate  with  incomplete  infonnation.  MOBILE  ROBOT  most 
operate  in  an  industrial  environment  and  thus  most  be  aUe  not  only  to  transit  to  die 
desired  woric  area,  but  also  to  perform  assembly  tasks.  (Because  only  die  first  mission 
is  relevant  to  AUV  at  diis  ponnt.  only  the  transit  execution  will  be  covered.)  The  world 
model  which  MOBILE  ROBOT  dqiends  iqxm  has  bodi  static  fixed  obstacles  and  moving 
obstacles  (Remtxdd  1986,  pp.  81-84). 

The  vehicle  planning  and  execution  is  carried  out  by  a  hierardiical  control 
system  very  nearly  like  Isik’s  and  Me3fsters  diiee-tier  hierarchical  control  model 
Command  flow  and  generation  are  executed  in  die  classic  waterfall  mediod.  A  global 
padi  plan  and  executor  is  reqxmsible  for  the  hi^iest  levels  of  decision-making  and 
adqNation.  An  expert  system  at  the  higher  level  determines  the  route  using  a  cube-based 
r^aesentation  of  ftee-qmce.  The  global  path  planner  must  transform  parameters  of 
deciskau  based  on  the  overall  route,  otetacles  or  obstructions,  and  path  constraints 
(percentage  deviation  allowed  for  varioos  missions)  into  cartesian  coordinates  through  an 
intermedfatte  sequencer.  This  in  turn  passes  the  geometric  coordinates  to  the  Navigator 
expert  sysiem  module  ndiich  most  conmd  and  interpret  sensory  ouqnit  for  nav^Eation  and 
recognition  of  various  obstructions  and  provide  adiqitability  strategies  for  local  deviations 
to  the  path.  Cartesian  cootdinaies  are  translated  to  vehicle  subsystem  actions  which  are 
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in  turn  passed  to  die  pilot  level  (which  corresponds  to  die  NFS  guidance  level).  An 
eiqieit  system  actually  coordinates  vehicle  actions  at  diis  level  to  avoid  contradictoiy 
guidance  system  actions  (Rmnbold  1986.  p.  85).  The  software  architecture  is  shown  in 
Figure  24i. 

2.  Procedural  Expert  System  (Esprit  Project) 

Procedural  expert  systems  are  die  object  of  this  cooperadve  research  between 
the  University  Amsterdam  and  Pramentec  of  Paris  on  an  industrial  robot  (Nfeijer  1990, 
p.  65).  Essentially  what  has  been  constructed  is  a  mission  executor.  Meijer  and  his 
ctdleagnes  have  constructed  a  model  known  as  the  Exception  Handling  Model  A  stack 
structure  is  used  to  store  the  current  (q)erati(ms  dut  die  robot  is  performing.  The 
operations  that  the  robot  can  perform  are  classified  according  to  complexity.  As  with  any 
robotic  qiplication,  planning  and  initial  scheduling  is  conducted  offboard  the  robot 
Adiqitive  scheduling  is  generally  required,  as  well  as  generation  of  recovery  plans,  to  deal 
with  any  interruption  to  the  ineplanned  q^erations  (Meijer  1989,  pp.  65-66). 

The  Excqition  Handling  htodel  attempts  to  achieve  the  planned  behavior  and 
provides  a  series  (rf  prioritized  strategies  for  recovery.  Like  many  other  robot  models,  it 
structures  them  in  heuristics  around  the  general  functions  of  mrniitoring,  diagnosis  and 
response  in  a  loose  hierarchy.  Fault  trees  are  used  in  die  diagnosis  part  to  trace  a 
componem  fitilure.  Recovery  plans  are  gmierated  from  diis.  Each  possible  strategy  is 
checked  for  feasiMlity.  The  system  will  defauh  to  a  rescheduling  mechanism  if  recovery 
addi  the  current  goals  is  not  possible  (Meijer  1989,  pp.  66-67). 
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Figure  24i.  Software  Cmtrd  in  the  Karlsruhe  Robot 


The  Procedural  Expert  System  itself  is  programmed  in  LISP  and  consi^  of 
a  knowledge-base  which  contains  the  vehicle  and  environmental  model  states  and  the  so- 
called  Knowledge  Area.  These  are  essentially  structures  similar  to  rules  which  have 
prerequisite  facts  that  make  up  an  interface.  These  have  associated  with  them  some  type 
of  procedural  code.  This  is  the  Procedural  Expert  System*s  mediod  of  encqtsuladng 
general  plans  and  domain-specific  plans.  It  is  very  nearly  a  paradigm  of  polymoiphism. 
A  structure  similar  to  an  inference  engine  selects  die  Knowledge  Area  to  be  executed 
depending  on  its  facts  being  resident  in  the  knowledge  b)>%.  Goal-achieving  Knowledge 
Areas  can  essentially  invdce  one  another  in  a  fashion  similar  to  the  classic  forward¬ 
chaining  mechanism  of  rule-based  systems.  Constraint-based  backtracking  is  available 
to  assist  in  truth  maintenance  for  the  knowledge-base  (Meijer  1989,  pp.  70-75). 

Exception-handling  is  structured  into  knowledge  areas  specifically  designed  for 
that  purpose.  These  invtdce  the  regular  task  achieving  knowledge  areas  (Meijer  1989,  pp. 
70-75).  Although  stack  •  Knowledge  Area  interaction  is  not  explained  in  detail,  there  is 
mention  (rf  pursuing  new  goals  should  that  become  necessary.  In  diat  case,  the  next 
available  goal  would  be  removed  fiom  the  stack  for  activation.  Tasks  have  a  himarchical 
flavor,  yet  the  underiying  reasoning  is  not  developed  into  a  true  hierarchical  software 
architecture. 

D.  SUMMARY  AND  EVALUATION 

This  limited  survey  of  AUV  software  architectures  indicates  that  there  is  some 
conceptual  agreement  in  architecture  but  wide  division  in  implementatimi.  Rule-based 


systons  are  popular,  but  are  implemented  in  different  fashions.  Subsumption  is  part  of 
several  architectures,  yet  it  is  not  effected  in  the  manner  that  Bnx^  originally  devised. 
The  TASC/NUSC  model  is  most  similar  to  NFS  AUV  n  in  terms  of  Missicm  Executor 
design.  However,  the  TASC/NUSC  model  makes  a  fiirdier  divisitm  for  task  execution 
managers  which  die  NFS  model  does  not  The  TASC/NUSC  model  implies  that  there  is 
an  object  or  module  to  monitor  each  of  the  critical  evolutions.  SINTEF  Coiporation’s 
object-otknted  AUV  model,  SAOOR,  has  similarities  to  the  NFS  AUV  n,  Init  it  assumes 
a  more  distributed  missicm  executor.  Actually,  there  is  no  distinct  mcxlule  known  as  the 
executor  in  SACOR.  Most  of  this  functicmality  is  derivable  from  the  Watchdog  and 
Captain  mcxhiles.  Unfortunately,  the  Obtain  mcxlule  is  merely  a  sequencer  with  no 
intelligence,  heuristic  or  otherwise  (although  intelligence  is  planned  for  possible 
incorporaticm  as  the  project  matures). 

The  layered  hierarchical  control  mcxlels,  while  presenting  a  non'iraditional  approach 
to  robotics  architecture,  present  a  very  credible  method  of  testing  software.  While  all 
researchen  may  not  agree  on  Brooks’s  subsumpticm  of  behaviors  modd,  die  incremental 
additicm  and  vetifkaticm  of  the  software  is  currently  being  carried  out  in  AUV  n. 
Diviskm  of  decision-making  and  ccmtrol  in  AUV  II  is  evident  in  only  two  explicit  layers. 
Impliddy,  the  navigaticm  mcxlule,  pattern  recognition  software,  vehicle  ccmditicm 
monitaring  mcxlule,  and  guidance  module  are  all  in  an  intermediate  level  Thus,  cxie 
might  be  able  to  infer  that  the  hierarchical  models  might  be  closest  in  design  to  AUV  n. 
Most  of  these,  however,  have  scrftwaie  redundancy  in  each  layer  as  Isik  and  hfeystel’s 
Intelligent  Mobile  Autoncmous  System  (IMAS)  does.  The  NFS  AUV  n  software 


architecture  wtnild  best  fit  in  the  hybrid  category.  It  is  not  stricdy  hierarchical  nor  is  it 
a  layered  control/subsumption  model.  Clearly,  it  is  not  the  traditional  horizontal  model. 
The  current  implementation  of  the  Mission  Executor  (as  later  explained)  is  situation-event 
based.  Combining  this  aspect  with  the  hierarchical  structure,  one  must  conclude  that  the 
NFS  AUV  n  software  is  a  new  variety  of  the  hybrid  model. 


a 
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m.  THE  C  LANGUAGE  INTEGRATED  PRODUCTION  SYSTEM 

This  chapter  provides  an  overview  of  the  C  Language  Integrated  Production 
System  (CLIPS)  and  the  arguments  for  its  use  as  the  ongoing  tool  for  construction  and 
extension  of  the  Mission  Executor  of  tte  Autonomous  Underwater  Vehicle  in  both 
simulatitm  and  die  actual  testbed,  AUV IL 

A.  MAIN  FEATURES 

CLIPS  was  developed  to  meet  the  need  for  a  low-cost,  portable,  rapid  prototyping 
tool  which  could  be  used  in  the  construction  of  both  real-time  and  non-real-time  systems. 
The  effort  was  begun  in  1985  at  the  NASA  Johnson  Space  Cento*  with  construction  of 
a  prototype.  The  intent  of  the  design  was  for  CUPS  to  mimic  features  of  both  the 
Automated  Reasoning  Tool  (ART),  the  List  Processing  (LISP)  language  and  (Official 
Production  System  5  (OPS5).  The  Software  Technology  Branch  at  NASA  was  essentially 
successful  in  this  venture.  CUPS  version  3.0,  the  first  to  be  released  to  users  outside  of 
NASA,  was  distributed  in  1986.  Since  that  time,  the  expert  system  has  undergone  several 
revisions.  CUPS  is  a  forward-chaining,  rule-based  tool  which,  like  die  production  systems 
it  is  based  on,  uses  the  Rete  algorithm  for  i»ttem  matching  and  inferencing.  (NASA  1991, 
pp.  xiii-xiv) 

CUPS  rules  are  generally  constructed  of  facts  in  the  relation-attribute  and  associated 
value  form  on  the  left  side  of  the  production  arrow  (  »>  ).  The  asserted  facts  which  are 
(Hoduced  are  placed  on  the  ri^t-hand  side.  Figure  3>1  dqiicts  a  sample  deftule  which 
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may  be  found  in  die  Missicm  Executor  system.  Facts  may  have  constraints  placed  on 
their  values.  Logic  expressitms  such  as  conjuncdon,  disjunction  and  negation  (in  die  fonn 
of  and,  or,  noi)  may  also  be  attached  to  them.  CXIPS  allows  for  efficient  pattern- 
matching  on  variables  on  the  left-hand  side.  Procedural  statements  such  as  If...then...else 
and  while-loqis  are  available.  Truth  maintenance  is  available  through  die  use  of  the 
logical  construct  to  assert  a  fact  (or  facts)  which  has  a  dependency.  Retraction  of  tme  of 
the  odginal  left-hand  side  facts  removes  dw  suppon  for  that  assertion.  This  is  illustrated 
in  Figure  3*2.  A  substantial  numeric  function  library  is  available  for  logical  comparistm, 
some  ctMiversions  of  standard  units  to  others  (degrees  to  radians  and  vice-versa),  and 
special  numeric  evaluations.  CLIPS  input  and  output  (I/O)  is  very  similar  to  LISP  and 
the  Commtm  LISP  Object  System  (CLOS).  Formatted  input  and  output  is  nearly  identical 
to  USP.  (NASA  1991,  pp.  5-47) 

Earlier  versions  of  CLIPS  did  not  include  any  object  orientation  or  user-defined 
functions.  User-defined  functions  had  to  be  written  in  the  source  language.  Version  S.O 
now  includes  the  CLIPS  Object  Oriented  Language  (C(X>L)  which  exhibits  properties  of 
both  SmallTalk  and  CLOS,  and  user-defined  functions.  It  supports  a  frame  hierarchy  of 
classes  and  objects.  Presently  it  only  supptms  specialization  inheritance  (although  there 
is  a  way  to  emulate  generalization).  Like  other  object-cniented  systems,  CLIPS  5.0 
provides  inheritance  and  strict  interfaces  (message-handlers)  for  accessing  the  data  in 
<4>jects.  Procedural  constructs  such  as  daemons  may  be  attached  to  objects  and  fire  upon 
basic  actions  such  as  initialization  or  modification  of  slots  in  an  object  Impressive 
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(defrule  monitor-battery 
(action  monitor) 


(cunent-time  ?time&:(>  Tdme  ?*giiaidline*)) 

=> 

(assert  (battery  time-critical)) 

(assert  ( guidance  shift-power-soorce))) 

•  This  rule  is  typical  of  an  automated  control-type  rule 

?time  is  a  constrained  variable.  This  rule  will  only  fire  if 
?dme  is  greater  than  the  global  variable  ?*guard^*, 
which  must  be  elabmated  at  run  time. 

On  the  right-hand  side,  two  facts  are  asserted.  Hie 
second  one  is  typical  of  a  control  fact  It  causes  another 
module  to  execute  anodier  rule  (semandcally-linked). 


Figure  3-1.  A  Sanqple  CUPS  Rule 
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(defruk  Condnue.umestricted 

(logical  (equipnient.Btatus 

nonnal) 

(navigation.status 

within_tolerance) 

(maneuvning_status 

nonnal) 

1 

3 

1 

1 

feasible) 

(enviaiiinient_status 

nonnal)) 

*> 

(assert  (overall_niissi(Mi_status  CcMitinue.unrestiicted))) 

If  any  cf  the  five  facts  <m  die  left-hand  side  are  retracted,  die 
consequent  overall_niission.status  will  also  be  retracted. 


Figure  3-2.  Use  of  the  CLIPS  Trudi  Maintenance  Construct 


pcdymorphism  allows  even  a  casual  piograininer  to  create  a  definethod  which  will  operate 
differently  when  presented  with  arguments  of  different  types.  (NASA  1991,  pp.  5-18) 
Efficiency  in  CLIPS  is  due  primarily  to  the  use  the  Rete  Algoridim.  A  recent 
syndiedc  benchmaik  conducted  by  Mettrey  at  Bell-Nocthem  Research  demonstrated  that 
systems  using  the  Rete  Algorithm  were  substantially  more  efficient  and  faster  dian  their 
compedtors  which  used  a  different  pattern  matching  schmne.  Writing  condidmis  dut 
specify  a  rule  is  instandated  only  if  a  pattern  cannot  be  matched  by  any  fact  in  die 
knowledge  base  is  a  powerful  feature  of  the  Rete-based  tools.  Tempwal  redundancy,  a 
common  characteristic  of  knowledge-bared  systems,  is  used  to  great  advantage  by  Rete- 
based  tods.  Rete  saves  repeddve  information  on  nodes  and  propagates  tmly  changes,  thus 
increasing  efficiency.  (Mettrey,  1991,  pp.  19,30) 

In  addition  to  low  cost,  CLIPS  has  been  designed  with  a  great  deal  of  flexibility. 
It  has  many  features  cf  more  expensive  tods,  including  die  following; 

•  CUPS  does  not  require  the  entire  oivironment  to  be  available  on  the  operating 
system  to  run  an  apfdication.  Executable  modules  can  be  created  ndiich  allow 
ecomnomical  deliveiy  of  die  qiplication.  (Riley  1987,  pp.  33-40) 

•  CUPS  is  poctaUe  to  any  environment  supporting  a  C  compiler. 

•  Sevmi  different  conflict  resdution  strategies  are  available  rather  than  just 
depth-flrst-search.  (NASA  1991,  pp.  28-31) 

CLIPS*s  ody  apparent  weakness  is  an  absence  of  pattern-matching  on  the  left- 
hand  side  for  objects  in  CUPS  Object  Oriented  Language  (CX)OL).  Some  NASA 
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prognunmen  readily  admit  dot  this  is  an  impediment  in  srnne  applications.  On  the 
other  hand,  there  are  woik-aroand  solutions  to  this. 

B.  DEVELOPING  CONTROL  EXPERT  SYSTEMS  IN  CLIPS 

The  need  for  a  low-cost  tool  such  as  CLIPS  is  evident  by  its  wideqnead  use  in 
the  government,  commercial,  and  academic  communities  and  by  the  proliferation  oi 
software  systems  constructed  in  CUPS  since  it  was  first  released.  A  recent  advisory 
released  by  the  NASA-Johnson  Space  Center  indicated  tfiat  over  3000  usors  are 
programming  in  CUPS  (NASA  1991,  p.  xiv).  The  range  of  applications  has  included 
robot  control  expert  systems,  advisoiy  systems,  intelligent  tutoring  systems  and 
numerous  embedded  qyplicatitms.  As  this  research  is  primarily  directed  at  high-level 
contrd,  a  small  sample  of  some  of  the  ctmtrol  applications  completed  or  in  development 
follows. 

Case  Western  Reserve  University’s  Centn-  for  Automation  and  Intelligent  Systems 
Research  develt^ied  a  model-based  space  station  autonomous  power  control  system  in 
1988.  The  simple  model  used,  essentially  a  terrestrial  one,  requires  the  power  control 
system  to  dynamically  schedule  many  pown-  loads  for  a  station  with  but  a  single  power 
source.  Three  phases  of  power  control  are  modeled:  a  normal  phase,  an  emergency 
jdttse.  and  foe  recovery  phase.  Heuristics  are  embedded  in  foe  rules  which  deal  with 
predictions  and  consequences  of  possible  load  fiulute.  The  operamr  is  warned  of 
impending  failure  as  the  system  moves  forough  phases  of  warning,  critical  and  failure. 
If  the  operator  takes  no  action,  the  system  will  automatically  shed  die  failing  load. 


Only  seven  basic  supervisory  rules  are  used  to  control  the  system.  All  use  very  ba^ 
CUPS  patterns  and  virtually  no  frame-based  templates  or  oomptex  objects.  (Vezina 
1988,  pp.  211-220) 

The  Center  for  Engineering  Systems  and  Researdt  (CESAR)  at  Oak  Ridge 
National  Laboratory  has  implemented  a  robotic  expert  system  in  CUPS  version  4.0 
tdiich  allows  a  robot  to  find  and  operate  plant  controls  in  a  hostile  atnurqrheie  sudi  as 
a  smoke-laden  contrd  room.  The  object  ci  dtis  was  to  implement  madiine  learning. 
(Spelt  1989,  pp.  8-15) 

Eloee  Computek  Incorporated  has  been  developing  a  guidance  system  simulator 
known  as  KMARS  (Kixrwledgic/Geometry-based  Mobile  Autonomous  Robot  Simulator) 
for  robotic  vdiicles.  This  includes  both  a  knowledge  base  (written  in  CUPS  4.3)  and 
a  geometry  base.  The  simulator  plans  and  executes  motion  for  a  point  robot  in  a  two- 
dimensional  environmenL  Ibe  expert  system  calls  C  language  functions  to  execute 
procedural  activities.  The  eiqiert  systmn  attempts  to  determine  if  a  geogrqrhical  goal 
can  be  located  by  a  limited  range  sensor.  If  the  goal  cannot  be  "seen”  by  die  smiaor, 
a  subgoal  is  created.  When  the  point  vehicle  reaches  die  subgoal  area,  the  vehicle 
sensors  are  again  activated  to  see  if  the  goal  can  be  detected.  The  overall  purpose  in 
dus  system  is  to  explore  unknown  envirotunents  widi  little  a  ptiori  knowledge  (Cheng 
1990,  pp.  822-830).  This  qifdication  is  similar  in  nature  to  the  general  autonomous 
underwmer  vehicle  problem  and  is  one  more  indicator  that  CUPS  is  a  proper  tool  fbr 
this  apptication. 
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C  COMPARISONS  AND  BENCHMARK 

The  leoent  viitual  expk»ioo  oi  available  expen  system  tods  has  made  selection 
of  the  appropriate  tool  for  an  qtplicatioii  a  daunting  task.  William  Mettrey  of  Bell* 
Northeni  Research  recently  compared  five  wdl-known  tools  [ART-IM,  VAX  C^S, 
Level  S,  KES]  fir  adqitability  and  suppott  of  the  dtese  commonly  desired 
chaiacieristics: 

•  knowledge  rqxesentation 

•  inference 

•  development  environments 

•  delivery  environments 

•  documentation 

•  support  (Mettrey  1991,  p.  19) 

Mettrey  found  the  inferencing  capabilities  of  CLIPS  to  be  very  strong.  The  Rete 
algorithm  iqxn  which  it  is  based  is  a  very  qrpealing  and  efficient  algoridun.  Deqnie 
this,  Mettrey  criticues  CLIPS  for  not  having  fiame-base  reasoning.  (At  the  time  of 
poUirifing,  CUPS  version  5.0  with  foe  CUPS  Object  Oriented  Language  had  not  yet 
been  released.)  Finfoer,  the  development  environment  is  not  as  advanced  as  some  of 
foe  other  tools  (Mettrey  1991,  pp.  20-21).  CLIPS  5.0  is  currendy  being  updated  to 
include  a  more  advanced  development  environment  wifo  a  mouse-drivni  interfoce. 

NaturaDy,  there  was  a  strong  tendency  to  measure  less  esoteric  facets  oi  die 
development  tools.  Mettrey  devised  a  synthetic  benchmark  that  consisted  of  typical 
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roles,  consisting  of  object-attribule-vslue  facts  (some  wiA  constraints)  on  the  Idt  side 
and  fact  assertions  on  die  right  side,  which  are  commonly  found  in  rule-based  expen 
systems.  Seven  dififiaent  cases  were  examined.  In  the  first  case,  twenty-five  typical 
rules  were  placed  in  die  program.  Uming  began  at  ron-dme  and  ended  at  2S0  rok- 
fifings.  The  number  of  rules  inserted  and  die  role-firing  termination  pram  were 
increased  by  a  factor  of  two  in  each  of  the  succeeding  cases.  Timing  analysis  was 
conducted  on  a  Sun  3  workstation,  a  Macintosh  n,  and  a  VAXstadon  3100.  Knowledge 
Engineeting  System  (KES)  and  QJPS  were  first  compared  on  die  Sun  3  workstation. 
CLIPS  outperformed  KES  quite  dramatically :  a  rado  of  12.7  to  1  in  speed  on  the  low- 
end  case,  and  19.5  to  1  in  die  hi^-end  case  of  200  rales  with  a  terminadcm  pdnt  of 
2000  rules.  On  die  Macintosh  n,  CUPS  performance  over  Level  5  was  less  dramadc 
but  sdll  significant  VAX  Official  Piodiredon  System  5  (OPSS)  performance  on  the 
VAXstadon  3100  was  marginally  better  dian  CUPS.  CUPS  fired  rules  slighdy  faster 
than  die  Automated  Reasoning  Toed  for  Informadon  Management  (ART-IM).  This  is 
interesting  inasmuch  u  CUPS  was  designed  around  the  characteristics  of  ART  in  its 
origiiud  form  although  NASA  claims  diat  no  actual  ART  source  code  was  used. 
Mettrey  notes  that  Inference  Cotporadon,  whidi  developed  ART,  later  used  CUPS  as 
the  base  fir  its  development  of  ART-IM.  (Mettrey  1991,  pp.  22) 

Aldioo^  the  benchmarks  were  useful  in  determining  performance  among  die 
tools,  a  metric  sudi  as  dus  is  of  Umited  value.  Extenaons  on  performance  in  all  types 
of  systems  omnoi  be  pretficted  on  the  basis  of  diis  evaluation.  Theories  6[  rule 
groupings  have  evolved  which  faidicate  that  performance  may  be  drastically  changed  by 


Ae  onfer  in  which  rules  are  grouped  m  a  rule-baaed  program.  One  of  the  four  expert 
system  tods  evaluated.  Level  5,  does  not  use  the  Rete  algorithm. 

Nonethetess,  what  can  be  observed  from  Mettrey's  benchmark  is  diat  CLIPS,  for 
its  cost,  is  the  best  forward-chaining  expert  system  tod  among  Aose  evaluated. 
Further,  version  5.0  (and  its  forthcoming  subsequent  version)  has  an  objea-oriented 
systems  which  is  more  tightly  coupled  than  ART-IM,  uAich  lacks  a  few  of  the 
commody  recognized  object-oriented  features  such  as  multiple  irAeritance. 

D.  PORTABILITY 

As  this  is  a  specifically  stated  goal  of  initial  CLIPS  development,  it  is  not 
surprising  that  portability  is  a  notable  strengA.  CLIPS  can  virtually  be  used  in  any 
enviromnent  which  supports  a  standard  C  compiler.  Mettrey’s  synthetic  benchmark 
described  above  used  CLIPS  as  Ae  standard  of  comparison  because  it  was  the  only  tool 
which  ported  to  all  three  versions  of  hardware  previously  described  (Mettrey  1991,  pp. 
28). 

CLIPS  applications  can  be  completed  as  compifed  run-time  modules  m  C  or  m 
the  mterpreted  mode  of  the  full  CLIPS  envircmment  As  the  envimunent  is  not  large 
(currently  less  than  1  megabyte)  and  the  speed-up  of  the  compiled  versirm  oidy  slight, 
in  many  applications  it  may  not  be  to  much  advantage  to  cmivert  to  a  compiled  version 
excqrt  to  save  memory. 

Further  supporting  wide  portability  is  die  fact  that  CLIPS  comes  wiA  its  source 
code,  b  Aus  can  be  customized  for  virtually  any  qrplication.  The  CLIPS  Advanced 
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Prognunming  Guide  gives  explicit  instructitMis  for  creating  nin-time  modules  and 
embedding  CLIPS  in  q)plications  in  which  the  main  program  is  written  in  C,  Ada  or 
FORTRAN.  Run-time  modules  are  created  by  first  compiling  the  CLIPS  source, 
loading  all  files  of  an  qiplicadon  to  the  CLIPS  environment,  and  then  using  a  command 
known  as  constructs-tOK:  to  convert  the  total  aiq;>lication  program  to  a  series  of  C  files. 
After  modifying  die  header  files,  the  CUPS  source  main  program  is  modified  and  the 
CUPS  modules  together.  The  run-time  modules  are  not  suitable  for  an 

application  which  has  the  build/eval  functions  (NASA,  1991b,  pp.  99-104).  Thus,  if  an 
Artificial  Neural  System  is  to  be  simulated,  it  must  be  achieved  through  dynamic 
salience  only. 

Embedding  an  application  requires  a  similar  approach.  CUPS  user-defined 
functions  may  be  called  via  the  CUPS  FuiKrticm  Call.  Constructing  objects  requires  the 
CUPS  Make-instance  call  in  the  source  language.  After  the  Load  Constructs  command 
is  given  for  all  of  the  CUPS  functions,  the  newly  created  C  files  are  linked  (NASA, 
1991b,  pp.  35-98).  Porting  an  embedded  application,  like  a  run-time  module,  is 
relatively  simple. 

The  GESPAC  MPU30HF  with  Motmola  68030  CPU  cutiendy  used  in  the  AUV 
is  well-suited  to  handle  C-based  tools.  Thus,  porting  the  Mission  Executor  should  not 
be  a  monumental  task.  The  current  vehicle  software  is  ported  via  RS232  intetfoce.  The 
OS-9  operating  system  is  designed  as  a  multi-processing  envimunent  and  dius  can 
easily  support  CUPS. 
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IV.  ONBOARD  INFORMATION  PROCESSING 

This  chapter  examines  the  data  flow  between  the  Mission 
Executor  and  other  modules.  The  Mission  Executor  receives  its  path  constraints  and 
baseline  commands  firtmi  the  proposed  interfaces  to  cooperating  modules  (depicted  in 
Figure  4-1)  are  discussed. 

A.  DOWNLOADING  POSTURES  AND  COMMANDS  FROM  THE  MISSION 

PLANNER 

The  offboard  Mission  Planner  was  successfully  implemented  by  Ong  (Qng  1990) 
and  is  being  extended  by  Caddell  (Caddell  1991).  It  provides  a  best  three-dimensional 
path-to-goal  given  chart  features  of  the  regitm  in  which  it  is  to  operate,  time 
requirements,  and  special  path  ctmstraints.  The  Mission  Executor’s  most  important 
functions  in  a  normal  transit  are  to  receive  waypoint  and  command  data  (denoted  as  a 
path)  from  the  Plaiuier,  interpret  the  movements,  convert  the  path  postures  to  reference 
postures,  and  properly  sequence  the  movement  The  path  data  are  passed  to  the 
Executor  in  a  file.  The  Executor  converts  the  plan  to  a  series  of  waypoint  objects  and 
then  begins  the  monitoring  of  diese  objects.  The  other  functitms  which  the  Executor 
carries  out  while  important  are  generally  exception-handling  relative  to  normal 
operations. 

This  is  not  to  categorize  the  Mission  Execute’s  interplay  with  the  Planner  as 
simply  one  of  a  conversion  unit  serving  a  high-level  planner.  The  Mission  Executor 
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must  reason  about  diese  waypoints  and  die  associated  speeds.  If  the  original 
commanded  speed  for  a  particular  waypoint  is  no  longer  valid  due  to  an  unplanned 
deviation  from  course,  then  the  Executor  must  call  the  Navigatitm  module  for  an 
iqxlated  speed  to  get  to  the  goal  cm  time. 

B.  UPDATING  FROM  THE  OBSTACLE  AVOIDANCE  DECISION  MAKER 
Conceptually,  the  Obstacle  Avoidance  Decision  Maker  has  die  responsibility  for 
processing  packaged  sonar  data  from  the  pattern  recognition  module  and  relating  it  to 
specific  obstacles.  Decisions  on  both  the  type  of  obstacle  (moving  or  stationary)  and 
the  avoidance  maneuver  (decrease-speed,  increase-speed,  dive,  ascend)  are  determined 
and  passed  to  the  Mission  Executor.  One  pn^sal  for  the  manna*  in  which  it  will  pass 
data  is  an  obstacle  alen-and-direction  flag  followed  by  a  template  of  the  form: 

•  obstacle  identification 

•  relative  distance 

•  relative  orientation 

•  time 

•  movement 

•  parameters  of  movement 

The  direction  flag  is  sent  merely  to  alen  the  Executor  to  a  real-time  report 
Receipt  of  the  template  data  allows  the  Executor  to  call  the  RePlanna  with  the 
information  while  also  flagging  Guidance  to  be  ready  for  imminent  receipt  of  new 


reference  postures  fw  the  new  path>to-goal  referenced  to  a  new  origin  (the  cuirent 
geographical  positicm).  A  low-level  reflexive  response  can  also  be  passed  direcdy  to 
the  guidance  ccmtiollCT  bypassing  the  Mission  Executor  in  the  case  of  an  unplanned 
obstacle  close-aboard  (Healy  1990). 

C  UPDATING  FROM  THE  SONAR  MODULE 

The  Mission  Executor  normally  depends  upon  t^stacle  identification  and 
orimitation  data  passed  from  the  Obstacle  Avoidance  Decisicm  Maker.  Thus,  sonar  data 
from  the  pattern  recognition  module  is  filtered  through  the  Obstacle  Avoidance  Decision 
Maker.  Currently  however,  this  is  only  a  conceptual  framework  as  die  Obstacle 
Avoidance  Decision  Maker  has  not  yet  been  fully  realized.  To  bridge  this  temporary 
software  gt^,  a  proposal  by  Floyd  to  pass  a  four-bit  flag  direcdy  from  the  pattern 
recognition  module  has  been  implemented  (Floyd  1991).  Depending  cm  the  pattern 
received,  the  Missitm  Executor  will  opt  for  a  right  turn,  a  left  turn,  an  ascent,  at  any 
combinatitm  of  these  for  gross  avoidance.  It  will  then  request  a  new  route  plan  from 
the  Renanno*  if  there  is  sufficient  need.  Consideration  of  all  features  of  an  object,  as 
in  the  template  described  above,  cannot  be  achieved  in  diis  ctmfiguration  withmit  the 
intelligence  provided  by  the  Obstacle  Avoidance  Decisionmaker. 

Therefore,  the  granularity  to  determine  if  an  obstacle  requires  a  dgmfiamt 
deviation  from  the  original  track  such  that  a  new  route  must  be  planned  becomes  quite 
coarse.  The  Mission  Executor  takes  this  inm  account  when  performing  the  so-called 
"sensibili^  check"  when  the  RePlanner  provides  a  new  route.  The  presence  of  any 


obstacles  on  the  new  initial  leg  is  quickly  checked.  More  importantly,  however,  the 
currrat  gross  vehicle  tnetfy  state  is  balanced  against  die  distance-to-go  altmg  the  new 
route.  Nonedieless,  due  to  the  weakness  of  diis  method  without  the  intervention  of  an 
Obstacle  Avoidanoe  Decision  Maker,  diere  may  be  several  crossover  situations  in  n4iich 
a  small  deviation  from  the  original  path  may  unnecessarily  cause  a  new  route  to  be 
planned.  This  is  not  cause  for  concon  in  the  AUV  II’s  testing  envirmunent  at  the  NFS 
pool  because  the  turns  are  90  degrees  by  default  Further,  die  pattern  recognititm 
software  has  the  ability  to  disregard  obstacle  features  which  may  be  distorted  while 
chan^g  heading,  thus  avoiding  an  even  great  error  in  maintaining  the  desired  path 
(Floyd  1991). 

D.  INTERFACE  WITH  THE  REPLANNER 

The  RePlanner,  a  knowledge-based  padi-planner  which  uses  an  optimized  real¬ 
time  A*  search,  attempts  to  plan  a  new  path-to-goal  based  on  knowledge  of  die  goal 
state,  the  current  geographical  location  and  special  path  constraints  passed  by  die 
Executor.  It  tolerates  in  four  dimensions;  three  standard  cartesian  dimensitms  and  a 
fourdi  dimension  of  heading  or  azimuth  (Bonsignore  1991).  The  RePlanner  receives 
periodic  updates  from  the  envirtmmental  database,  allowing  it  tt>  replan  the  new  route 
from  any  specified  origin. 

The  RePlanner  is  alerted  to  the  need  to  replan  by  a  function  call  frcmi  die 
Executor.  A  flag  and  the  coordinates  of  die  current  location  are  transferred  to  the 
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RePlanner.  It  constructs  a  new  plan  in  the  same  mannn  as  the  Planner,  using  a  priori 
knowledge  of  the  environment.  A  file  of  new  waypoints  is  returned  to  die  Executor. 

E.  UPDATING  FROM  THE  VEHICLE  CONDITION  MONITOR 

Cunendy,  the  Vehicle  Condition  Mtmitor  is  not  modeled  at  the  real-time  fevel. 
The  vehicle’s  internal  worid  is  modeled  as  a  set  of  sensor  objects  which  measure  die 
sub^stem  components.  Objects  are  instantiated  for  power  sources  sudi  as  die  array  of 
batteries  for  subsystem  power  and  propulsion  support,  control  system  indicators  for 
rodders,  planes  and  propellers,  sonar  power  status  indicators  for  the  four  onboard 
sonars,  onboard  computer  temperature  sensors,  navigation  instrument  fault  sensors,  and 
power  sources  for  envirvmmental  sensors.  These  have  default  guard-line  and  red-line 
ranges  which,  when  violated,  cause  an  alarm  to  be  sent  to  the  decitdcm-making  levels. 
An  automated  turn-key  operation  is  fiint  generated  which  attempts  to  balance  an 
equipment  failure  or  impending  failure  by  Ininging  a  redundant  ^tem  on-line,  if  such 
redundancy  has  been  provided.  If  the  equipment  is  critical,  it  may  degrade  the  mission 
status  to  continue-mission-restricted  or  to  aboit-tnissk>. 

The  data  interface  must  confnrn  to  strict  object  interfaces,  as  the  subsystem 
sensors  are  modeled  as  objects.  Each  tAject  is  queried  by  its  own  appropriate  message 
sent  at  tegular  intervals  fiom  the  Executor.  A  message-handler  checks  die  subsystem 
sensor  object’s  slots  to  see  if  an  operating  parameter  such  as  a  temperature  or  power 
level  falls  within  die  guaidline  range.  If  it  does  not,  the  qipropriate  response  is 
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genmted.  This  may  initiate  dw  tunkey  operation  or  may  just  cause  die  Executor 
decisum  makers  to  be  notified.  The  object  hierarchy  is  pictorially  described  in  Figure 
4-2. 


F.  INTERFACE  WITH  THE  GUIDANCE  SUBSYSTEM 

The  rad  result  of  die  Mission  Executor  functions  must  be  a  series  of  refraence 
postures  and  commands  to  die  Guidance  subsystem.  Guidance  is  an  intermediate-level 
function  n^iich  has  an  algoiidunic  reasoning  system  widiin  it  It  converts  higji-level 
decisions  and  reference  postures  to  low-level  commanded  postures  for  the  Autqiilot 
module.  A  fiinctira  call  within  die  rules  of  the  Missira  Executor  generates  an  alert  to 
die  Guidance  module  to  prqiare  for  receipt  of  data  and  commands.  The  reference 
posture  is  modeled  as  an  objea  and  so  passed  to  the  Guidance  module.  Commands 
from  the  Executtv  to  Guidance  are  sent  as  flags. 
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F1giira4-2.  System  Monitor  Objects 
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V.  DESIGN  OF  THE  PROTOTYPE  EXPERT  SYSTEM 

This  du^Mer  explores  the  design  of  the  prototype,  interface  limitations, 
and  the  justifications  for  use  of  several  of  the  software  consuucts.  This  design  is 
intended  to  cover  most  AUV  situations,  but  die  current  implementation  is  not 
considered  in  any  fuhion  to  be  fully  comprehensive. 

A.  PHILOSOPHY  OF  DESIGN:  REASONING  ABOUT  SEVERAL  WORLDS 
The  current  NPS  AUV  n  architecture  is  the  result  of  an  incremental  developmoit 
which  began  in  1988  at  the  conclusitm  of  research  for  AUV  I.  Evolutitmary  changes 
in  subsequent  software  desig'  '*^ulted  in  the  need  for  a  hi^-level  ctmtiol  module.  The 
Mission  Executor,  SKIPPER,  attempts  to  fill  tiie  role  of  hi^>level  director  while 
integrating  decisions  based  on  input  from  tiiree  worids:  the  vehicle’s  int^al  systems, 
the  external  environment,  and  the  mission  itself. 

Simply  put,  the  Mission  Executor  <^)erates  on  more  tiutn  one  laym’  of  symbolic 
reasoning.  Decisions  are  modeled  heuiistically  rathor  than  in  a  strictly  algoritiunic 
fashion.  High  level  decisions  require  a  knowledge  of  the  status  of  low  levd  items  to 
get  a  "sense  <rf  the  system"  and  assess  whether  a  mission  can  be  carried  out,  whidi  is 
tile  ultimate  goal.  The  low  level  events  then  drive  the  broader  decisions.  The 
requirement  to  model  tiiis  lends  itself  naturally  to  a  hierarchical  design,  but  one  that  is 
priofity-sitoation  based.  Most  AUV  guidance/control  systmns  are  closed-loop  and  are 
equipped  to  deal  with  routine  maneuvering.  The  Executor  exists  mainly  to  deal  with 
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excqxions  to  nonnal  maneuvering  wfaicb  cannot  be  dealt  in  a  strictly  algoritbnuc 
fasbion.  Its  leasoning  results  in  intenupt  commands  to  guidanoe  wbicb  controls  the 
autofrilot  If  there  are  no  deviations  firom  die  tiack  caused  by  any  of  die  three  worids 
that  AUV  most  deal  with,  dien  the  Executor  merely  fulfills  a  role  of  sequencer  of  data. 
The  current  implementation  allows  for  the  interface  of  system  monitor  functions  whidi 
often  are  found  on  lower  levels  in  odier  systems.  However,  as  die  cuirent  AUV  n 
architecture  does  not  charge  the  lower  levels  widi  diis  reqxmsilHlity,  bodi  die 
intermediate  and  hi^  level  monitoring  tasks  are  delegated  to  the  Executor  for  the 
present  (This  is  expected  to  be  replaced  by  an  intermediate  level  module  which 
responds  to  analog-to-digital  ouqnits.) 

Aldioogh  not  all  experiential  knowledge  may  be  encoded  in  rules,  diere  is  reason 
to  believe  AUV  missions  can  be  bounded,  at  least  for  die  time  being.  Some  previous 
research  has  suggested  that  AUV  behaviors  might  in  fact  be  standardized.  Hie 
University  of  New  Hampshire’s  Marine  Systems  Engineering  Laboratory  (MSEL)  and 
the  Naval  Underwater  Systems  Center  (NUSC)  cooperated  in  the  research  of  some 
standard  situations  in  vriiich  an  AUV  mi^t  find  itself.  The  resulting  matrix  entitled 
"Generalized  ftoblem  vs  Contingency  Alternatives  Matrix”  they  derived  is  interesting 
for  its  philosophy.  Situations  are  classified  in  three  categories  of  problems:  mission, 
envirorunent,  and  internal  fiulures.  These  have  a  one-to-one  correspondmioe  widi  the 
dvee  worlds  that  die  NFS  Mission  Executor  is  trying  to  model  at  a  high  level.  The 
audiors,  Westneat  df  MSEL  and  Qearwater  of  NUSC,  determined  that  die  AUV 
control  system  must  be  able  of  srnne  linuted  decision-making  for  a  (relatively)  short 
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minion.  Loafer  mistiont  will  require  some  form  of  madune  teaming  vduch  will  not 
necessarily  involve  a  neural  net  (Westneat  1991,  pp.  29-33)  F^ure  5-1  rixnvs  a 
facsimile  of  die  NUSC  matrix. 

Hus  view  of  Ugli  level  control  as  essmtially  handling  excqnioas  to  normal  tranat 
and  operatkms  is  embodied  in  die  Mission  Executor.  Some  of  die  implications  of  die 
matrix  merit  serious  cooskteratioa  sriiite  odiers  are  sinqily  beyond  the  scope  of  cunent 
technology.  Vducte  selfiqisir  is  hi^ily  unlikely  in  a  mechanical  failure  situatioo 
unless  diis  term  refen  only  to  equipment  which  has  a  redundant  system  or  power  source 
available. 

To  implement  the  design  described  sbordy,  a  number  of  assumptions  about 
external  modules  are  made.  As  some  external  modules  remain  to  be  completed, 
external  module  interfaces  such  as  diose  described  in  Ouqiter  IV  are  modeled  as  data 
files  supervised  by  control  rates.  Scenarios  are  imptemented  by  instantiated  data  fiom 
die  files  much  as  the  oqiected  module  would  perfonn.  Rtes  exist  to  model  a  module 
operating  in  two  modes:  (1)  supplying  data  driven  by  demand  from  die  Executor  and 
(2)  supplying  data  driven  by  events.  Examples  of  type  one  are  a  command  from  die 
Executor  to  die  Navigator  module  to  provide  the  current  location  or  a  command  to  the 
RePlaimer  to  provide  a  new  list  of  waypoim  postures.  Event-driven  data  are  iiqiuts 
such  as  the  irikial  list  of  waypoints  from  the  offboard  Missioa  Planner,  obstacle  data, 
and  navigatkm  iqiorts  sudi  as  waypoint  data.  This  is  depicted  in  flguv  5-2. 
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FifUK  5*1.  Naval  Underwater  Systems  Center 
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The  basic  overall  design  consists  of  a  knowledge  base  of  rules,  facts,  and  objects. 
This  knowledge  base,  although  currently  stand-alone,  is  expected  to  interact  with 
modules  such  as  the  Obstacle  Avoidance  Decision  Maker,  and  call  external  modules 
such  as  RePlanim  and  Guidance.  Figure  5*3  describes  in  a  simple  grq)hical  fashion 
the  overall  schema  for  the  Executor  a  base  of  rules  exists  for  each  functional  (Le., 
situational)  area:  maneuvering,  luvigatitxi,  subsystem-mtmitoring,  mivironmental,  and 
spedalized  missioa.  The  rules  interact  widi  the  object  base  and  cache  of  fiicts  to 
produce  the  required  guidance  commands.  Several  global  variables  are  used  to 
represent  performance  parameters. 

The  rule  base  is  instituted  in  a  hierarchical  fsishion.  The  Overall  Mission  Assessor 
tabulates  the  status  of  each  functional  area.  If  no  deviations  occur  during  the  course 
of  the  mission,  the  missitxi  status  remains  at  its  default  status,  continue.unrestricted. 
It  views  each  area  in  two  levels:  critical  and  failure.  The  critical  level  indicates  that  the 
functional  area  has  suffered  some  sort  of  restrictive,  non-catastrophic  loss  of  c^)ability. 
This  can  be  on  the  order  of  loss  of  ncm-mission  essential  equipment  oc  a  temporary 
maneuvering  restriction  such  as  a  obstacle  avoidance  which  takes  it  from  its  principal 
directitxi  of  travel  This  results  in  a  missicm  status  of  continue  with  restrictions.  Tire 
failure  level  indicates  that  the  functional  area  has  suffered  a  majtre  loss  of  curability 
such  as  loss  of  mission-essential  equipmmit  or  irubility  to  marreuver.  This  essentially 
results  in  a  mission  status  of  mission  abort.  The  mission  restriction  category  can  later 
be  Ufked  if  tire  vehicle  recoven  in  ample  time.  If  not,  tire  mission  restriction  remains 
or  worsens  the  overall  mission  status  K)  mission  abort. 
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The  functional  role  areas  also  have  a  hierarchy  in  diemselves.  A  functional 
assessor  exists  at  the  of  each  role  base  to  cache  knowledge  about  the  functional 
area.  This  then  passes  the  functional  area  infonnation  to  the  main  fact  base  which 
causes  the  executive  decision  roles  to  be  fired.  (The  distinction  between  main  fact  base 
and  functional  area  fact  base  is  merely  conceptual  as  the  CLIPS  inference  engine  does 
not  perform  this  discrimination.)  A  schematic  of  this  is  shown  in  Figure  jM. 

B.  SEQUENCE  OF  CONTROL 

The  sequence  of  control  in  a  role-based  system  often  contains  a  relatively  high 
degree  of  mm-determinism  because  of  its  declarative  nature.  While  there  are  certain 
tasks  which  must  be  accomplished  in  procedural  order,  as  mentioned  before  the 
Executor  is  a  system  which  reasons  about  situations  which  are  normally  beyond  a 
closed-loop  control  system.  The  CLIPS  inference  engine  does  a  depth-first  search  of 
a  fact-node  hierarchy,  but  the  actual  implementation  hierarchy  traversal  is  not  quite  as 
clear. 

Input  mission  postures  are  first  uploaded  from  the  Mission  Planner  offboard  the 
v^cle.  As  at  the  time  of  this  writing  not  all  AUV  n  software  modules  are 
implemented,  the  current  version  of  the  Executor  assumes  tiiat  a  simple  data  file 
structure  exists  as  the  interface  between  the  Missim  Planner  and  the  Executor.  The 
input  postures  read  from  the  file  are  given  to  a  Mission  Interpreter  which  places  a 
posture  into  the  jwoper  object  format  and  designates  tire  high-level  classification  of  the 
posture  configuration  as  a  transit  or  specialized  mission.  As  the  lower  Ifv?! 
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Figures^.  Functional  Area  Hierarchy 


configuration  of  die  posture  (depth-level  turn,  ascent,  dive)  is  unknown  at  that  time,  a 
comparison  is  made  from  waypoint  to  waypoint  and  the  lower  level  action  instantiated. 

Not  only  a  large  influence  for  its  own  fimctional  area,  the  Equipment  Status  area 
(or  intetchangeably  Subsystem  Monitoring  Area)  exerts  a  notable  influence  in  other 
areas.  Separate  rules  exist  for  each  equipment  area  (sonar,  control  system,  navigation 
instrument,  environmental  sensor  and  special  mission  equipment)  and  the  respective 
power  source.  A  continuous  monitoring  rule  polls  each  equipment  area  equipments 
which  are  out  of  out  of  normal  operating  limits.  These  limits  are  normally  parameters 
of  sustenance  such  as  potential  in  volts  or  power  in  watts.  If  a  mission  essential 
equipment  fails,  it  causes  a  failure  in  both  the  Equipment  Status  area  and  in  the  area 
with  which  it  is  associated.  For  example,  loss  of  the  diving-plane  controls  causes  a 
maneuvering  loss  and  a  mission  essential  equipment  loss.  If  an  auxiliary  power  source 
exists  for  an  equipment,  it  can  be  used  in  the  event  that  the  normal  source  fails. 
Similarly,  equipment  with  redundancy  has  the  capability  to  have  its  functions  shifted 
to  the  alternate  should  it  fail. 

An  Equipment  Status  Assessor  awaits  the  results  of  equipment  polling.  If  an 
equipment  fails,  then  the  equipment  (previously  classified  as  mission  essential  or  not 
mission  essential)  will  cause  its  equipment  classification  rule  to  fire  and  the  Status 
Assessor  will  tabulate  the  results.  If  a  mission-essential  equipment  or  a  sufficient 
quantity  of  non-mission-essential  equipment  fails,  the  equipment  status  area  will  suffer 
a  major  failure. 


The  instantiadra  of  the  lower  level  action  attribute  of  the  configuration  actually 
takes  place  within  the  Navigation  rules  upon  the  occasion  of  waypoint  airivaL  Anodier 
rule  which  plays  a  large  part  in  the  navigational  aspect  of  high  level  control  is  die 
assessment  of  progress  along  the  mission  track.  The  rule  does  a  simple  comparison  of 
overall  distance  along  tire  track  with  current  location.  It  then  orders  a  replan  of  the 
current  track  if  the  current  speed  and  progress  made  are  not  compatible  with  reaching 
the  goal  area  on  time.  A  very  simple  energy-consideration  function  checks  whether 
there  is  sufficient  propulsive  power  to  get  to  the  goal. 

Other  navigation  rules  cover  specially-monitored  depths:  both  yellow  dqiths  and 
red  depths.  If  the  depth  sonar  indicates  that  the  AUV  has  encountered  a  yellow  depth 
area,  AUV  calls  the  Navigator  for  a  check  of  the  required  depth  in  that  area.  If  the 
observed  depth  does  not  match  the  required  depth,  guidance  is  ordered  to  reverse  course 
and  the  replanner  is  called.  If  a  red-depth  violation  is  indicated,  guidance  is  called  to 
reverse  course. 

Maneuvering  rules  cover  several  areas.  Hrst  and  foremost  are  the  obstacle 
avoidance  rules.  The  highest  priority  rules  cover  emergency  situations  such  as  detecticm 
of  an  obstacle  close  aboard.  The  various  orientations  of  the  obstacle  relative  to  tire 
AUV’s  heading  will  prompt  a  right  oc  left  turn,  an  ascent  or  a  full  stop  (drive  motors 
sttipped)  or  a  combination  of  these.  These  are  heuristic  turning  rules  which  proposed 
by  Floyd  which  can  produce  an  effective  gross  avoidance  for  the  AUV  so  tiiat  the 
RePlarmer  can  then  be  invttired  for  fiuther  path  refinement  (Floyd,  1991).  Floyd’s  table 
upon  which  the  Executtx’  rules  are  based  is  reproduced  in  Table  S-1.  This  is  essentially 
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an  interim  measure  which  will  be  replaced  by  a  m(»e  detailed  avoidance  procedure  in 
the  forthcoming  Obsou;le  Avoidance  Decisicm  Maker  module. 

Deiectitm  of  an  obstacle  at  the  lan^  of  the  smiar’s  limits  is  another  fimctitm 
covered  by  maneuvering  rules  of  the  Mission  Executor.  Because  of  die  AUV  stmar’s 
relatively  limited  distance,  avoidance  action  must  be  taken  early.  The  obstacle  is 
initially  checked  for  its  potential  to  hazard  die  AUV.  This  is  dependent  cm  die 
obstacle’s  bearing  drift  and  its  relative  beating.  This  is  recorded  and  a  collective 
obstacle  heuristic  is  instantiated  to  deuumine  whether  a  proportional  amount  of 
obstacles  will  block  the  AUV  to  the  left  or  right.  A  gross  avoidance  maneuver  is  then 
commanded  to  bring  AUV  away  from  the  obstacle  and  allow  the  RePlanner  to  plan  the 
new  avoidance  path  widi  qipropriate  mapping  waypoints. 

The  procedures  for  an  update  to  an  obstacle  are  essentially  the  same.  If  the 
obstacle  is  still  a  hazard,  then  further  avoidance  and  replanning  are  necessary.  There 
is  a  danger  that  this  will  result  in  a  significant  deviation  from  the  path  and  that  this  will 
result  in  a  mission  abort  This  is  accounted  for  in  the  functional  area  assessment  rule. 
If  an  obstacle  is  no  longer  a  danger,  then  its  collision  danger  is  recorded  as  such  and 
thus  it  is  not  considered  in  the  collective  obstacle  assessment 

Other  rules  in  the  maneuvering  functional  area  cover  special  depth-changing 
’  evolutions  such  as  diving,  ascents,  and  surfacing.  The  control  systems  have  an 

•  inherently  large  influence  on  these  special  maneuvers.  If  a  control  systmn  fails  during 

one  of  these  rituation,  that  results  in  an  automatically  commanded  maneuver  to 
guidance  to  correct  the  attitude  and  level  the  vessel  at  a  safe  depth  or  change  the  speed 
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at  which  the  maneuver  is  proceeding.  An  unprq)er  obstacle  clearance  can  also 
precipitate  changing  one  of  these  special  evolutions. 

The  Envinmment  rules  have  a  similar  anrangement  An  Environmental  Assessor 
tabulates  the  number  of  sensors  which  have  performance  readings  which  are  out  of 
limits.  If  it  is  an  essential  equipment  such  as  the  pressure  transducer,  the  loss  will 
cause  a  functional  area  loss.  If  it  is  a  non-mission  essoitial  equipment,  die  loss  will 
only  cause  a  minor  degradation  to  the  environment  functional  area. 

While  basic  AUV  maneuvering  connol  and  navigation  will  be  the  primary  focus 
fcr  some  time,  incoiporation  of  specialiad  missions  will  eventually  bectnne  important 
Specialized  Mission  rules  have  a  different  influence  than  the  previous  functional  areas. 
Most  of  diese  rules  do  not  take  effea  until  the  transition  to  a  special  missicm 
configuration  at  the  conclusion  of  the  transit  The  exception  to  diis  is  a  special  misnon 
area  equipment  failure.  A  functional  mission  area  failure  occurs  if  the  special  mission 
equipment  foils.  Future  versions  will  most  likely  have  an  alternative  to  undmtake  a 
secondary  mission  if  the  primary  missitm  cannot  be  fulfilled.  The  mission  area  rules, 
although  not  implemented  in  the  current  vosion  ,  will  probably  be  based  loosely  on 
MacPhoscm’s  description  of  AUV  missitms  in  tmnplare  form  (MacPherstm,  1988,  pp. 
59-75). 

As  mentioned  previously,  the  fimctitmal  area  assesscns  report  to  die  overall 
mission  assesstv.  This  is  located  in  a  block  of  rules  known  as  the  Mission  Executive, 
which  constitutes  the  highest  level  of  reasoning  in  the  Executor.  The  overall  mission 
assessor  is  insulated  from  details  of  the  reports  by  die  functitmal  area  supervisors.  It 
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only  lemains  for  the  overall  assnsOT  to  tabulate  the  results.  If  complete  failure  in  any 
area  other  dian  the  envinmment  fuiK:ti(mal  area  occurs,  a  mission  abort  results.  Less 
than  a  complete  failure  in  a  functional  area  may  cause  a  degradatum  to  continue  witit 
restrictions.  A  missicm  degradation  results  in  a  phenomencm  known  as  status  lock.  A 
missiixi  status  of  mission  abort  results  in  the  two  other  status  rules  being  removed. 
Thus,  even  a  seeming  recoveiy  cannot  override  a  mission  abort.  A  degradation  to 
continue  with  restrictions  can  improve  to  continue  intresfriciiedif  recovery  occurs  in  the 
mandated  time  frame. 

Misskm  abort  causes  the  vehicle  padi  to  be  replanned  for  a  pre-planned 
rendezvous  point  It  may  be  die  origin  of  die  mission  or  an  intermediate  pmnt  which 
facilitates  recoveiy  by  the  launching  platform.  Continue  with  restrictions  allows  the 
vehicle  to  try  to  recover  from  its  maneuvering,  navigation,  or  equipment  restriction.  In 
the  future,  it  may  also  allow  for  altering  of  the  mission. 

Certain  high-level  behaviors  are  modeled  using  the  Artificial  Neural  Paradigm 
suggested  by  Giarratano  (Giairatano  1991,  pp.  228-229).  This  application  of  the 
salience  of  a  rule  is  useful  in  differentiadng  between  a  high-level,  less  frequent  action 
and  a  lower-level  frequendy  performed  action.  The  philosq>hy  for  using  salience  in 
dus  manner  is  that  a  situation  (pattern  match)  which  may  cause  a  mission-abort  or 
mission-restriction  usually  requires  immediate  or  timely  reaction  and  certainly  takes 
precedence  over  a  routine  action  such  as  a  nonnal  turn  or  depth-change  in  a  normal 
deep-water  environment  The  emo-gency-actimi  rule  must  be  fired  befcne  other 
semantically  lowm’-inimity  rules  on  the  agenda.  This  (however  loosely)  heuristically 
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models  a  submarine  commander’s  "situatkxial  awareness”  in  an  emergency.  It  might 
also  be  moened  to  a  focus  of  attention  apjnoach,  such  as  that  modeled  by  Blidberg  and 
his  associates  at  die  Marine  Systems  Engineering  Labocatory  (Blidberg  1990,  pp.  40- 
41).  Flgttre  S>5  illustrates  an  example  of  diis. 

Salience  is  also  used  in  some  background  functions  sudi  as  die  sequmicing  oi  die 
misskm  timer  and  the  continuous  loop  which  queries  die  slots  of  die  system  monitors. 
Still,  it  is  used  qiaringly.  SKIPPER  still  retains  a  strong  declarative  nature. 

The  Mission  Executor  must  send  not  only  reference  postures  to  die  Ouidanoe 
module,  but  commands  as  well  Many  the  commands  must  initiate  time-constrained 
lower-level  actions  while  the  assessment  of  a  particular  functional  area  status  is  in 
progress.  The  commands  must  be  a  aeries  of  well-understood  actions  uriiich  will  place 
die  vehicle  in  a  safe  cmifiguration  when  a  casualty  occurs.  The  table  of  these 
commands  is  shown  in  Table  5-2. 

C  TRUTH  MAINTENANCE  AND  THE  ROLE  OF  UNCERTAINTY 

L  Maintaining  a  Cowristent  Knowlcf^  Base 

As  important  as  sensing  data  and  scheduling  actions  based  on  it  is  the 
maintenance  ofconasiency  in  the  knowledge  base.  In  a  rule-based  system  this  becomes 
acutely  important  udien  die  feneration  of  a  new  action  through  a  control  fact  is  based 
on  some  odier  events.  If  the  events  whidi  would  cause  that  action  are  no  longer  valid, 
then  it  may  be  the  case  diat  die  generated  centred  fact  is  no  longer  valid.  In  such  a  case 
it  would  be  necessary  to  go  and  remove  the  fact  This  can  invtdve  complex  rol(».  It 
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TABLE  5-2.  Executor  Comnuuids  to  Guidance 

Bade  Maneuver  Older  Objectof  Older 

TURN  tum-left  nidder 

TURN  turn-right  rudder 

DEPTH-CHANGE  asoend-XX  planes 

DEPTH-CHANGE  dive-XX  planes 

DEPTH-CHANGE  surface  planes 

SPEED-CHANGE  Increase-Speed  drhre-motors 

SPEED-CHANGE  Decrease-Speed  drive-motors 

SPEED-CHANGE  STOP  drive-motors 

SPEED-CHANGE  HOVER  hover-ditusters 

XXs  depth  in  inches  or  an  indicated  safe  depth  variable 
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can  also  be  achieved  dnough  die  use  die  QJPS  logical  construct 
previously  in  Chapter  m.  One  can  withdraw  a  fact  which  is  no  longer  consistent  and 
is  no  longer  supported  (NASA,  1991). 

Nonetheless,  diere  are  occasions  when  the  logical  construct  is  not  as  useful.  These 
situations  usually  require  some  sort  of  search.  Certain  high  level  decisions  may  require 
knowledge  of  previous  decisions.  This  is  paidculariy  true  for  the  high  level  mission 
decisions.  A  previous  instantiadon  of  abort  mission  cannot  allow  for  improvement  to 
a  better  status  as  the  abort  mission  should  (mly  take  place  when  all  relevant  options  to 
continue  die  missioo  have  been  explored  and  found  insurmountable.  The  status  lock 
feature  helps  to  maintain  the  high-level  configuradon  while  sdll  allowing  for  die 
necessary  actions  of  avoiding  obstacles  and  performing  routine  navigatitm  enroute  to 
die  misskxi  origin  or  designated  rendezvous.  Overall  mission  status  becomes  "frozen.” 

2.  Uncertainty 

Uncertainty  plays  a  significant  role  in  a  system  such  as  die  Mission 
Executtv.  In  fact  die  primary  reason  for  using  a  fnward-chaining  rule-based  tool  such 
as  CLIPS  is  that  there  is  some  knowledge  but  a  great  deal  of  uncertainty  abmit  the 
external  environment  What  is  known  about  die  enviitmment  can  best  be  classified  in 
heuristics.  A  specific  area  of  uncertainty  that  the  Mission  Executor  must  reason  about 
is  the  presence  of  obstacles.  Rqiort  of  an  obstacle  at  short  range  automatically 
generates  a  command  from  the  executor  (emergency  situation)  but  rqiort  of  an  obstacle 
at  die  limit  of  die  sonar  is  a  different  matter.  The  obstacle  is  assigned  a  confidence 
foctor  nduch  comes  from  die  Sonar  Ptocesang  Suite.  Obstacles  of  high  or  medium 


confideiloe  cause  the  path  to  be  replanned  The  rationale  is  that  the  %ther  away  an 
obstacle  is  detected  the  less  radical  a  turn  is  necessary.  This  often  results  in  less 
deviation  from  the  original  track,  saving  both  mission  time  and  energy  cmisumption. 

D.  MISSION  DOCUMENTATION  AND  OBJECT  PERSISTENCE 

L  The  Need  fmr  High  Level  Mission  Documentation 

There  is  a  vital  need  for  documentation  of  AUV  missitms.  All  trf  the  AUV 
projects  now  in  development  at  various  facilities  around  the  country  have  come  to  rely 
on  some  data  recorded  onboard  the  AUV.  This  compilation  of  data  is  valuable  for 
several  reasons: 

•  it  can  be  analyzed  by  human  AUV  researchers  to  update  and  refine  the  AUV 
control  systems  (both  hardware  and  software) 

•  it  can  provide  an  idea  of  what  works  with  rule-based  systems  and  where  frilure 
in  reasoning  occurs. 

•  it  can  be  used  as  a  persistent  base  of  knowledge  for  "training”  AUV’s  in  situadmi 
assessment  (this  was  also  a  conclusion  of  Westneat  (Westneat  1990,  pp.  27-33)). 

Documentation  already  exists  within  the  NFS  AUV  n  Baseline  system  in  die 
form  of  die  Environmental  Database  which  contains  some  navigational  data  and  data 
tdxNit  obstacles  which  might  be  encountered.  A  missicm  log  is  maintained  by  die 
Navigator  module  in  much  the  same  way  that  a  mission  log  is  kept  by  die  navigator  of 
a  maritime  vessel.  However,  in  order  m  adequately  study  high-level  control,  a  mission 
log  must  also  be  kqu  of  hi^-level  decisimis.  It  can  be  regarded  as  a  form  of  oqnain's 
log  vidik^  records  die  state  of  the  mission  at  the  highest  level  and  justifications  for 


decisioiis  made.  At  a  standard  time  intoval  or  whenever  die  overall  mission  dedsioii 
changes,  an  entry  is  made  to  the  log.  This  is  accomplished  by  saving  objects  and  facts 
to  the  log  file. 


2.  Object  and  Fact  Persistence  in  the  Executor 

Object  persistence  in  a  database  refers  to  longevity,  its  ability  to  exceed  die 
life  of  the  executing  iqiidicadan  pro^am.  A  knowledge  base  no  longer  exists  at  die 
conclusion  of  an  execudon.  To  save  its  knowledge,  die  infocmadtm  must  be  loaded  to 
a  file.  Ofagects  are  saved  via  the  save-insuuu:es  cmnmand.  Facts  can  also  be  saved  by 
die  save  command  (NASA  1991,  pp.  169,  188). 
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VL  PROTOTYPE  IMPLEMENTATION  AND  SIMULATION 

This  duller  describes  dw  actual  proto^peimplemeiitatiofi.  Test  results 
are  discussed  at  the  conclusion  of  the  chapter. 

A.  CONTROL  CONSTRUCTS  AND  OBJECT  IMPLEMENTATIONS 

The  Missioo  Executor  implementatitxi  is  built  around  die  overall  missioo  state 
existing  in  one  of  three  fonns:  Continue.umestricted,  Continue.widLrestrictions,  or 
AborL.Missioo.  Continue.unrestricted  is  die  inidal  default  state  outlined  in  Chapter 
five.  This  state  only  exists  when  no  functional  area  is  critical  or  experiencing  failure. 
Most  of  the  rules  in  the  Execute  ate  based  on  missions  which  cannot  remain  in  the 
ideal  state  due  to  a  casualQr  or  discrepancy  in  die  mission,  vehicle,  or  environmental 
worlds. 

The  vehicle  reasoning  system  is  implemented  upon  the  download  of  the  mission 
plan.  This  triggers  die  rule  Misskm.Tlmer,  which  continually  binds  the  mission  time 
to  the  cunent  cratral  processing  unit  (cpu)  time.  A  timer  flag  is  ctmtinually  asserted 
in  this  nik  and  retracted  in  die  timer  manager  rule.  The  timer  manager  continually 
asserts  facts  which  trigger  other  polling  rules.  While  the  detailed  implementation  of  diis 
is  available  in  A]^ndix  A,  the  main  algorithm  is  shown  below; 

nad  (dnMLsoeoario); 
if  inUcte  ttiias  «  o|Knikiail,  iben 
"I*— f~~iiiiinn_nif ). 

Khile  not  end-or'ffle 

fCMl 
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nake  ponniejobject  (ddimited  million  datalineX 
adiridle; 

initiaHiie  vehicie-ienior,  minion,  environmental,  maneuvering, 
navigation 

end  if; 

while  not  tenninating  conditioo 

*  (completed  minion,  abort  to  lendesvoui,  abort  for  dymnic  recovery) 
mittiQit_tinie  :■  (current  qw  time  •  minion  itart  time); 
if  die  minion_tinie  :*  dme  of  Moie  event  then 
initantiate(dte  evemX 

if  die  minioit_tinie :« the  appropriate  documeotatko  time  interval  dien 

rfnt^mmnt  die  ««>««««»; 

allow  maaeuwering.  vefaicle^enaor.  minion,  environmental,  and  navigaiiao 
mlei  10  handle  any  excepdom  to  doied  loop  navigadon  n  diey  occur, 
propagate  changn  (fimcdonal  area  nperviionX 
anen  impact  of  ny  dimgea; 
propagate  recovery  or  abort  configmadons; 
end  while; 


Initial  development  of  the  Executor  actually  focussed  on  the  intenud  world. 
Coincidentally,  it  somewhat  resembles  the  model  used  by  Gianratano  for  his  small 
intelligent  database  outlined  in  the  CUPS  Objects  Manual  (Giarratano  1991a,  pp.  ISO- 
161).  Vehicle  internal  state  is  modeled  in  the  module  sensor,clp  in  which  aU  txiboaid 
equipments  are  represented  as  objects.  The  main  class  which  defines  an  equipment 
object  is  SYSTEM_MONITOR.  Since  there  are  no  actual  instances  of  this  object, 
SYSTEM_MONITOR  is  an  abstract  class.  From  it  are  derived  the  various  equipments. 
The  structure  of  the  class  iidieritance  hioarchy  is  discussed  in  Chapter  V.  The 
SYSTEM_MONrrOR  class  takes  the  form: 


(defdMS  SYSTEM^MONTTOR  Ctt-a  USER) 
(fkK  iype_oCjcadiiig) 

(ilot  rading) 

(slot  stMiis  (defnilt  aonnal)) 

(slot  Re(hindant_Equipn>ent  Ooitializesxily)) 
(slot  redlinejiigii  Oiiiliali»»-oiily)) 

(slot  gusidlinejiigh  OnitislizeHxily)) 

(slot  guvYiliiie_low  (initialise-otily)) 

(slot  iedlioe:_low  Onltialize-oiily))) 


The  abstract  class  SYSTEM_MONrrOR  shown  above  is  composed  of  sltxs  viiich 
describe  the  most  general  form  of  equipment  sensor  onboard.  This  is  easily 
configurable  for  various  subclasses.  Tlw  slot  type_of_ieading  is  commtm  across  all 
subclasses,  as  are  the  reading  (the  current  reading  recorded  and  propagated  by  the 
analog-to-digital  converter),  and  the  status.  The  slot  RedundanuEquipment  is 
elaborated  in  the  instance  ^clarations.  It  eidier  establishes  an  equipment  as  redundant 
with  a  similar  m  backup  equipment,  or  it  takes  on  the  value  NONE.  Most  equipment 
has  a  redline  reading  (either  high  or  low)  indicating  that  the  failure  point  or  equipment 
shutdown  limit  has  been  exceeded.  The  guardline  slots  exist  to  provide  the  equipment 
to  degrade  more  gracefully,  perhaps  initiating  the  turn-key  operation  to  energize  die 
redundant  equipment  or  power  source.  Naturally,  not  all  equipment  or  power  sources 
have  both  high  and  low  limits.  The  slots  which  are  not  applicable  can  be  set  to  NONE 
in  the  subclass  definition  where  the  message-handlers  which  depend  on  die  various  slots 
are  elaborated. 

The  various  subclasses  of  SYSTEM_MONrrOR  have  their  own  class  defiiutions 
and  respective  messa^-handlers  which  operate  on  instances  of  diose  classes.  Most  of 
the  message-handlers  in  this  module  are  of  the  daemon  variet)'.  These  message 
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handlers  are  activated  when  a  basic  action  such  as  insotitm  of  a  new  value  in  an  object 
slot,  deletion  of  a  slot  value,  or  leading  of  a  slot  value  is  performed  (NASA  1991,  pp. 
86-87).  In  this  case  reading  of  a  slot  value  is  done  by  a  polling  rule,  monitor-healdi- 
omtinuously.  If  the  value  read  exceeds  a  guardline  value,  then  it  often  places  the 
system  being  monitored  in  the  condition  of  critical.  If  the  sensor  redline  value  is 
exceeded,  tire  equipment  is  assumed  to  have  failed.  In  the  case  of  a  vehicle  ccmtrol 
system  such  as  the  rudder  or  diving  plaires,  there  is  also  a  message-handler  which 
checks  die  response  of  the  system.  This  often  means  positional  response.  If,  for 
example,  the  autopilot  generates  a  oxnmand  to  turn  left  and  the  rudder  moves  in  the 
wrong  duecdon,  then  the  system  is  assumed  to  have  become  critical.  An  example  of 
the  CX)NTROL_SYSTEM  class  and  two  message-handlers  follows: 


(defdass  CX)NTROL_SYSm(  (is-a  SYSTEM_MONTrOR) 
(slot  typejoLreadiiig  (ddault  potemiaI_in_volis)) 

(slot  oaoirol-type) 

(slot  response  (default  nonnal)) 

(message-taandler  get-reading) 

(message^iandler  get-reqxmse) 


(definessage-liaiidler  (XH4TROL_SYSTEM  ga^eading  after  Q 
(bind  TConind  (insianoe-name-to-symbol  (instancenuune  ?seli))) 
Of  (or  (and  (>  TSeifavading  ?self;guardlinejiigh) 

(<  Tsdfatading  Tselfaredlinejiigh} 

(nd  (<  7adf3eading  ?self:gui^ineJow) 

(>  Tselfaeading  ?self3tdlineJow)))  dm 
(asaen  (EquipmentjOridcal  CoauoLSystem  ?conirol)) 

else 

(if  (or  (>  7ae)f3cading  7self3edlinejii^) 

(<  7selfaeading  7seifaedline_low))  then 
(assert  (EqaipmenLPtilare  ComroLSystem  7contiol)) 
(send  7sdf  put-stttus  INCH’ERATIV^))) 
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(dcfioiestage-^aiidler  OONTROL_SYSTEM  get-reqxnse  iflerO 
Of  (neq  TMifseqMiise  nonnal)  itaen 
(men  (EquipmentjOitical  CootroLSystem  ?sell)))) 

Using  low  salience,  these  message-handlers  are  polled  by  a  rule  which  uses  an 
object  quay  do-for-all-instances  for  each  subclass  of  SYSTEM_MONITOR  interface 
with  rules  which  determine  if  a  situadon  is  applicable  to  die  failure  or  cridcal  situadon. 
Low  level  rules  which  determine  the  situadoii  often  have  the  most  complex  heurisdcs 
in  the  Executor.  However,  the  equipment  status  rules  are  uncomplicated,  as  evidenced 
by  the  following: 

(defrule  CoonoLSystenuFailure 
(EquipmenU^ailure  QmtroLSysiem  ?control) 

*> 

(if  (eq  7oantr«ri  Hover-Ttanutm)  then 
(men  (Equipnient_Mission_£s9entia]  no)) 
elM 

(anen  (EquipmenL.MiiiiaQ_Essential  yes))) 

(men  (EquipmencStanu-Assess ))) 

This  simply  says  that  any  failure  of  a  control  system,  unless  the  control  system 
is  the  hover-thrusters,  should  be  considered  missitm-essendal  and  that  requires  impact 
assessment  of  the  equipment  funcdonal  area.  The  assertion  of  the  Equipment. 
MissionJEssendal  fact  and  Equipment.Status-Assess  ctmtrol  fact  will  trigger  an 
equipment  status  assessment.  If  the  equipment  failure  is  a  failure  of  the  hover  dmisters, 
it  will  simply  be  noted. 

Objects  are  not  only  used  to  model  equipments,  but  also  (fecisions.  Decisions  are 
maintained  fcv  purposes  of  later  retrieval  in  reconstructing  the  missitm  and  in 
conducting  any  possible  m«;hine  learning  for  the  AUV.  The  current  decision  IS  kept 


in  an  instance  called  current.  Whenever  a  new  decision  has  been  made,  it  is  passed  to 


the  functxm  decisitm-change  which  copies  the  old  decision  to  an  object  and  in  turn 


replaces  all  the  characteristic  slots  of  the  cuntent  decision.  Maintaining  the  decision  is 


useful  not  tmly  for  mission  documentation,  but  also  in  resolving  conflicts  between 
states.  The  decision  objects  and  function  constructs  take  the  following  form: 

(deffimction  decuian-duage  (?the_type  ?ihe_nile  Tthejevd  Tthejacikn) 

(bind  Tname  (gentym*)) 

(make-inttnoe  'Inmut  of  DECISI(X4) 

(oopyHikHnstanoe  Tname  of  DBCISI(X4) 

(aend  [aureat]  put-type  7tbe_Q^) 

(aead  (cnnem]  put-nik  ?die_i^) 

(aend  [cunent]  pmjacttoo  ?lhe_nction) 

(aend  (cunent]  put<dedsiaQ_tnne  ?*inission_tioie*)) 


(deffunction  oopy-old-instance  (?in8tance) 

(aend  (tynibd*tt>-inataaoe-«ame  ?instance)  put-type 
(send  [cunent]  get-type  )) 

(aend  (aymbd-io-instanoe-iiaine  7insiance)  put-level 
(send  [cunent]  get-Ievel)) 

(send  (aymbol-io-insianoe-naiiie  ?instanoe)  put-action 
(send  [cunent]  get-actkn)) 

(send  (symbol-to-instanoe'name  Tinstance)  put-decision-iiine 
(aend  [cunent]  get-decision_tinie))) 


(defclMS  DEOSIW  Qs-a  USER) 
(slot  type) 

(sbXTule) 

(slot  level) 

(slotactiaa) 

(slot  decitiao_tinie)) 


Mission  documentatitm  is  is  actually  maintained  by  a  rule  which  uses  die  save- 


instances  and  save-facts  commands  to  save  the  mission-state  at  that  point  This  is  dtme 
at  a  specified  time  interval,  usually  every  twenty  seconds.  Facts  and  instances  normally 
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cannot  be  saved  together  in  die  same  file  using  save-facts  and  save-instances,  so  diat 
there  is  both  an  instances  log  and  a  facts  log. 


(defivk  DocumeaLMiniao 
Tdocumnit  <-  (document  minion) 

■> 

(if  (>  ?*mii«ionjinie*  7*T1nie_hitervil*)  itaen 
^aw-^naaoM  ”MitriaiLl^iiis*0 
(■mc-Ckis  "MiniaBLJjoc 

(bind  Tmniejiitervtl*  VTiaeJaumi*  2DjO))) 

Oenact  Tdocnment)) 

Simuladtm  evmits  are  also  modeled  as  objects.  An  event  is  made  up  of  its 
number,  its  time  of  instandadon,  the  event  trigger  (a  fact  asserdtm  or  instance  message 
sent  tt>  a  handler),  and  a  descripdon  of  the  event  for  ouqiut  The  rule  trigger  is  actually 
a  literal  string  kept  in  die  event_acdon  slot  of  the  object  EVENT_SC31EDULE.  When 
the  event  is  acdvated,  the  CLIPS  eval  funcdcm  is  used  to  instantiate  the  fact  or  object 
message.  The  global  variable  ?*cuirent_event*  updates  the  focus  to  the  next  cuirent 
event  The  event  is  actually  instandated  acdvadng  all  the  events  t^iose  event  times 
have  passed  and  have  not  yet  beoi  acdvated.  The  ouqiut  lines  shown  in  Ai^midix  A 
have  bemi  omitted  here  for  clarity  in  understanding  the  ruleAnessage-handler  interaction: 


(defcim  EVENT.,SCHEDULE  (is-«  USER) 
(akx  eveouw) 

(riot  evcnubne) 

(riot  enotacdon) 

(Ml  ottcnpuoof 


(driiMant»4Hnacr  EVENr^CHEIXAf  eMcaw-evant  priaauy  0 
(mil  TmftwuerioiO 

(bind  7*dn«atjaveDt*  (•*•  7*caR«nL.eveat*  1))) 


(ddiwie  wwjcfaBrtukijMHMiger 
(decfave  (saliaoe  -SOQ) 

Tevcm  <•  CKlisdalejevem  nex^jevem) 

(dfr^or^nitnoe  ((?eveot  EVENTJSC31EDULE)) 

(aid  (<  TevcmxventJinie  ?*inisiioq_t>ine*) 

(eq  TeveotavcoLPO  7*GiincnL.eveat*)) 

(Mad  7evait  execoie-evenO) 

(itma  Tevent)) 

B.  LAYERING  OF  RULES 

As  described  in  the  pieviotts  cluQ>ter,  rules  in  SKIPPER  are  layered  accofding  to 
level  of  reasoning.  The  lowest-level  rules  actually  carry  out  die  corrective  action  by 
ordering  Guidance  to  turn  left  or  ascend-to-safe-depth  or  ascend-24  (signifying  ascend 
ten  inches).  This  is  a  significant  break  frcnn  a  human  paradigm.  In  a  naval  vessel 
where  maneuvering  amtrol  is  conducted  by  humans,  no  human  controller  is  assumed 
to  be  faultlessly  competent  The  commanding  officer  frequently  cross-checks  verbal 
reports  and  orders  to  ensure  that  his  instructitms  have  been  carried  out  This  is  of 
particular  consequence  in  a  special  maneuvering  situatitm.  In  SKIPPER,  the  lower  level 
rules  are  assumed  to  be  competent  qierators  or  connollers.  For  example,  the 
maneuvering  rule  abnormaljdive  is  given  die  responsibility  to  order  Guidance  to 
decrease  the  speed  and  ascend  to  the  designated  safe  depth,  Ininging  die  vessel  to  a  safe 
configuration  bdore  it  propagates  this  situation  to  the  intermediate  level  assessment 
rule: 


(difhde  SbnoniiaLeK* 

(CflBHfnShMI  TOORfig) 

^ctta  dhe) 

(or  (Bqyjpmanrjyhiit  CowroLSyiteni  PliejCioniiols) 
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(CaU^Ouidwoe-Caniiiund  Decrease-Speed  Drive-Moton) 

(Call-Ouidanoe-Comaund  Asoend-?*^e_dqMta*  Planes) 

(assert  (inaneiivcring_abilit]r  Migorjtesiiictioa) 

(assert  (Maneiivcrii|g_Staitts_Aaess))) 

The  intemiedute  level  rules  ^ipear  to  be  candidates  for  ctxiflict  widi  lower  level 
rules.  Because  the  overall  mission  status  is  dependent  tm  rapid  propagation  of  changes 
from  the  assessment  rules,  the  assessment  rules  axe  given  a  higher  salience  value.  Some 
expmiments  with  die  axtificial  neural  system  paradigm  demonstrated  diat  dynamic 
salience  is  not  always  effective.  In  short,  the  focus  of  consistendy  incieasing  salimice 
in  a  particular  area  based  on  past  inputs  can  lead  to  a  delay  in  other  functional  areas. 
This  can  be  critical  if  the  odier  functional  area  is  about  to  fail  aldiou^  it  had  no 
previous  record  of  doing  so.  Assigning  a  hi^ier  salience  value  to  the  assessnmnt  rules 
gives  them  adequate  priority.  The  Maneuvering  Status  Assessment  rule  which  handles 
an  equipment  failure  and  is  linked  to  the  low  level  rule  above  is  an  illustration  of  this: 

(dcftnie 

(deciwe  (ialtenoe7*iii«eitver..saUeace*)) 

(EquipmaaJVIve  CoMtoLSyilcni  7ooiiirolA:(neq  Tcoopol  Hover-Tbniiigi)) 

at> 

(anm  (dediioa-dinieiiiBeuverintjKiNBiim 
|inpi«M_ei|iil|RiienUirihiic)) 

(MMR  (MmcuvCTingjSusm  •emdy.mmcted))) 

Its  sibling  rule,  which  evaluates  odier  types  ci  maneuvering  status  problems, 
tabulates  the  number  of  disctqiancies.  A  certain  number  of  discrqiancies  signals  dutt 


the  navigatioiial  tndi  is  too  ambitioiis,  requiring  an  unacceptable  number  of  obstade 
avoidance  maneuvers.  The  discrepancies  are  bound  to  the  global  variable 
?*maneuvefalrility_fBCtoc*  which  triggers  the  Maneuvering_Status_Assesanent  rule  and 
eventually  causes  a  missitm  abort 

The  overall  missioo  assessor  examines  die  current  status  of  all  functional  areas 
and  makes  a  detennination  on  die  state  of  die  vdiicle  mission.  At  dutt  point  die  overall 
mission  status  is  changed,  if  necessary,  and  the  results  propagated  down  to  die 
respective  mission  alxvt  or  mission  restricted  rules.  Because  of  the  length  of  diis  rule 
and  its  respective  function,  they  are  displayed  in  Figure  6>1. 

All  of  the  functional  areas  have  a  similar  structure.  Maneuvering  has  the  added 
feature  of  low  level  assessment  rules  which  examine  the  obstacle  object  base  to  see  if 
the  indicated  obstacles  pose  a  collisimi  danger.  This  added  assessment  requires 
examinatkm  of  several  object  slots  and  stmie  tabulations,  actions  which  lead  to 
inoeased  ov^iead.  This  overhead  is  cleariy  observed  in  the  simulation  runs  described 
Wlow. 

C.  USE  OF  FUZZY  LOGIC  AND  TRUTH  MAINTENANCE 

Truth  mainterumce  is  an  integral  part  of  the  mission  executor,  mostly  in  die 
highest  levels.  The  logical  construct  described  previously  in  chqiter  three  is  die  CLIPS 
environment-installed  method  oi  maintaining  die  integrity  oi  the  state.  The  vehicle’s 
initial  state  (hence  ideal  state)  rests  upon  a  foundation  of  all  functional  areas  bdng 
operational.  This  does  not  memi  duu  all  functional  areas  are  devmd  oi  any 
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(defilde  OvodLMiiiiiaLAaeaor 
Tdwccd  <- (OmalUiriHia^jMM  fMai) 
feqnv  <- (EqiqMMLStMBt  teqapneaLJttliit ) 

QltmgMioaJmai  Tmvjmm) 
0&wiwniaeiiiiLSiMi«TwviioaMc^jKaiM) 

(Spec JdMoQjSMu  ?VecmitriaQ_|^ 

TdMote  <•  (prepetMe  clHi^) 

■> 

(MnctMMife) 

Of  (eq  TeqdipaMiitjttM  aivor jUlore) 

(Mad  ?*RwniwiiLewn_ftitoB*  (4-  ?*R«rtinneLieed_fldlaw^  1)) 
ebe 

Of  (mi  4<M|wtj— 1— MpnpneiMLcriticel)  then 
Odi>d?*PbiciioMU»qLcriiicel*  (4?*IbDcti(»aUmL.ciiiicai* 
1)))) 

(if  (eq  TiiMBeiimjtfttiH  aeveidy_n«rictBd)  then 
(bM  ?*naiciiaBiUne_fbIiBe*  (4^  ?*FiiictioiiaLmLfrihBe* 

D) 

dK 

(if  (eq  ?iiiMieaver_jtttoi  RMricied)  diea 
(UmI  7*IbaciiaMLlKqjcriiicd* 

(4  ?*TbactioaeUwqjcriiiai*  1)))) 

Of  («q  7avr jMMH  otdjofjioknBoe)  dMo 
(biad  7*I%wiiaaiLmJdhae*  (4- ?*lbKtiaiiiLjnqjb^^ 

D) 

etae 

Of  (eq  ?Bav_|ttiBS  GrUed)  ttaea 

^  - ^ - ■ - 


(4  ?*lbKXioad.jmLcriiicai*  1)))) 

Of  (Mi7caviRaBaeaLiMBtBavorjdB«iaiiaa)ihea 


0f(eq7ipecadaiaLiatas  bdBMMB)dJB 
(bM  7*HBKtiaaiLpaLAibBe* 

(4  T^ftacdoaiLpeqJbihae  1))) 

(Tnwl  Ibariioael  IVobhaw 


n|w«  OrniD  Mislioo  Aaemneat  Rule 
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complicatiolii.  jant  that  die  comidicatioos  will  not  canae  the  vehicle  to  become  oiticaL 
The  essence  cf  dus  ideal  state  is  embodied  in  die  ftdlowing  lule: 

Oogical  (EqoiianeatJSttiBt  rannaO 

(MmeaveringjSttOts  anrearicted) 

(EBviroBnienLSmM  normal) 

OHwiaaikm_iSaiBa  witUnjailaance) 

SBadbie)) 

■> 

(deciriaa'diancB  OvenIL>fiariao  Oondnue'lifiiikKLJBiaMricted 
Hi^  CbminBa-MiariOD’VdflHW-iaatrklri^ 

^am  (Owaaiumarionjiatui  OomimiCLUnraBiricMd))) 

Any  fiulme  oi  a  pardcular  fiinctitMial  aiea  will  cause  the  mission  status  to  be 
retracted.  However,  the  fimcticmal  area  which  caused  the  change  in  ovenll  mission 
status  will  cause  the  overall  mission  status  to  change.  Thus,  just  as  the  overall  mission 
status  of  Continue_unres  trie  ted  is  being  retracted,  a  new  missitm  state  is  being  asserted. 
There  is  no  "statetess"  g^  in  mission  status. 

A  functional  area  failure  causes  a  mission  abort,  resulting  in  vehicle  recovery  or 
an  abort  transit  to  die  designated  rendezvcHis.  The  abort  status  is  cme  that  should 
remain  in  effect  until  the  vehicle  is  recovered.  However,  in  the  interval  between  die 
status  dumge  and  the  actual  vehicle  recovery,  diere  is  a  possibility  that  a  fimctkmal  area 
becoming  critical  could  later  attempt  to  cause  a  status  of  Oondnue.withJResttictions. 
There  is  also  the  possiUity  dwt  the  functional  area  recovery  rules  could  cause  a  new 
state  of  Oontinue_unrestrk:ted.  To  counter  any  possibility  that  this  could  happen,  a  truth 
maintenance  feature  of  status  lock  is  incorporated.  This  causes  the  misaon  assessor 
rule  to  be  mtdsed  or  removed.  Thus,  no  mission  state  change  can  occur.  This  rule  is 
depicted  below; 
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(defrole  AboiCMinian 
(dectare  (pdknoe  S0Q» 

(Ovqill_niiition.j»atni  Abonjniariao) 

Tdonge  <•  Onoiwpie-dHQfe  down) 

Tpoint  <•  (wmioiiit  Too) 

0«ina  Ipoiot) 

^coict  ?dime) 

(dedskiKlHnfe  OvcnUL>asikn  Abon.Minioa  Low 
lodt^MM»_wiriLjgplauwie_io_i<Kiajmder^^ 

(unddhik  OvcniUkfisikA.Anenar) 

(do-for-iiMtBioe  ((foourol  CXJNTROL JSYSIEM)) 

Ond  (cq  lOaoDolMMitt  IN(XBtAT1VEE) 

(neq  foooirol  Hover-TInttBn)) 

(propi  (Cill-OiiidMice-ConMBMid  innLjo^JfWMpflndcr  iiwqpoi^ 
(Clril<hdd«ioe»Owwii«id  MoeniL^^ 

Qprintoat  t  orlf  crtf  ”»»>  gtnwh^  Down  for  Dynnic  Reoovay  ««<”  atf 
‘^»»  Ihntponder  will  fnncdoo  for  2  hours  ««<”  cdf) 

(halt))) 

(Abon*Rottie)) 


Fuzzy  logic  is  used  in  obstacle  avoidance  rules  in  the  confidence  fiictor 
assignment  If  the  confidence  factor  is  hi^  to  medium  and  the  obstacle  is  within  the 
180  degiee  arc  about  die  bow  of  the  AUV,  then  the  obstacle  is  considered  to  be  a 
otdlision  danger.  This  confidence  factor  is  checked  whenever  an  obstacle  alert  flag  is 
sent  be  it  an  update  or  a  new  obstacle. 

(drfniBiMge-limdlcr  OBSTACLE  otMtacle-change  primary  0 
Qf  (md  (aq  7selfxoiifidenoe_fKtar  high) 

(eq  ?idfiooafidenoe_fiKtGr  medinm)) 

(or  (md  ^  7self:heariiig  2700)  (<•  Tseltbeating  3S9.)) 

(wl  (‘^  TKlf Atoriag  900)  ^  Tidf^bearing  0.))))  tben 
(send  TSeif  pitt-ooilisiOQ_daifer  YES) 

^■sen  (oollecti«e.obstade_asses«nem)) 
die 

^end  TSelf  put-ooUisioajdsnger  NQ))) 


D.  RESULTS 


Implementing  die  Mission  Executor  Code  involved  some  testing  trf  die  rules  to 
deiennine  if  die  overall  desired  terminal  action  could  be  generated.  In  diis  heuristic 


model,  the  inmnt  was  to  detennine  if  symbolic  high-level  leasooing  would  achieve  die 
desired  behavior.  Another  benefit  was  to  determine  if  the  reasoning  system  could 
lecognia  situations  and  try  to  iqiproximate  real-time  constrained  decision-maldng. 
Navigatkmal  wayptnnts  used  in  the  scenarios  are  based  (m  the  moctel  of  the  Naval 
Postgraduate  School  pool  by  Magrino  and  Floyd  show  in  Figure  6-2.  These  are  the 
same  used  in  evaluating  the  navigational  controller  (Magrino.  1991).  An  average 
mission  time  of  two  to  four  minutes  is  used  for  the  ideal  non-avoidance  path 
transit/tiiissitm.  The  scenarios  described  are  listed  in  Appendix  B  fiv  reference. 
Prtqwgation  effects  are  displayed  in  Table  6-1.  Run-times  do  not  agree  with  mission- 
completion  times  simply  because  mission  times  are  based  on  a  starting  time  which  is 
instantiated  upon  the  full  download  of  the  mission  navigational  plan,  often  a  full  2.0 
secmids  or  more  after  the  beginning  of  program  execution. 

Scenario  one  merely  tested  the  mf»t  basic  case,  pre-planned  mission  executitm 
monitoring  (waypoint  sequencing).  The  Autonomous  Underwater  Vehicle  (AUV)  was 
given  a  set  of  waypoints,  each  with  its  specified  estimated  time  of  arrival  as  a 
ctmstraint  At  the  tiiird  waypoint,  the  AUV  missed  its  time  constraint  by  a  considerable 
amount  (47  seconds),  enough  to  cause  the  Waypoint_DistanceTlme_Check  rule  to  alert 
the  navigation  assessment  rule.  A  time  difference  of  20.0  to  39.99  seconds  is 
ctmsideied  to  be  minor,  resulting  only  in  a  command  to  Guidance  to  increase  the  speed. 
A  time  differrace  of  40.0  seconds  or  mme  is  considered  to  be  a  major  time  deviation, 
resulting  in  a  command  to  increase  speed.  The  Navigation  Assessment  rule  uses  the 
heuristic  rule  that  four  navigation  problems  such  as  tins  cause  a  replan  of  the 
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Figure  6>2.  NFS  Pool  Mission  Schematic 
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TABLE  6-1  SCENARIO  RESULTS 


Major 

Status 

Change 


Recognitkm 


Assessment 


Overall 

Change 


Seen  1 
leactitm/ 
propagation 
times(secs)t 

Seen  2 

Seen  3 

Seen  4 

0.276 

0.452 

0.243 

0.244 

0.35 

6.55 

0.17 

0.16 

0.16 

0.14 

0.16 

0.15 
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navigational  waypoint  plan.  With  only  one  navigation  problem,  this  resulted  in  no  true 
change  in  the  navigation  status.  Nonetheless,  the  navigation  status  was  assessed  for  any 
possible  effect  The  only  effect  was  the  low-level  command  to  increase  speed  although 
the  current  navigation  status  was  propagated  to  the  ovoall  missitm  assess^. 
Recognititm  of  a  large  navigational  discrepancy  in  time  resulted  in  a  time  of 
propagation  of  0.28  seconds  from  the  Waypoint-DistanceHme.Check  rule  to  the 
Navigatkm  Assessment  Rule.  Recognition  that  this  was  not  a  change  to  status  todc  0.16 
seconds.  The  overall  elapsed  mission  time  was  3  minutes  30  seconds  with  18365  rules 
being  fired. 

Sceiuuio  two  tested  the  abiliQr  of  SKIPPER  to  recognize  an  untenable  obstacle 
avoidance  situation.  Both  short  range  obstacles  and  long-range  obstacles  were  tested. 
The  first  recogniticm  of  an  obstacle  close-aboard  led  to  an  ascent  to  safe-deptii.  This 
also  tested  a  rule  recognizing  possible  shoaling  or  grounding  of  the  vessel  The 
emergency  avoidance  maneuver  rule  began  its  time  check  of  the  avoidance  maneuver. 
An  obstacle  detected  at  long  range  led  to  assessment  of  the  obstacle  as  threatening  to 
the  AUV.  The  overall  maneuvering  status  was  changed  to  Continue.with_Restrictions. 
At  one  point  enough  obstacles  had  accumulated  to  cause  the  collective  obstacle 
assessment  rule  to  charactaize  the  situation  as  involving  a  critical  number  of  obstacles 
(heuristic  used  is  four  separate  encounters).  Later  the  collective  obstacle  assessment 
rule  determined  that  the  critical  point  had  been  breached  by  accumulation  of  too  many 
obstacles  along  the  track  (the  heuristic  here  is  that  too  many  obstacles  will  cause  too 
many  time-consuming  avoidance  maneuvers).  The  maneuvering  status  assessment  rule 
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detennined  that  this  was  a  functional  area  failure.  The  maneuvering  functional  area 
failure  then  forced  recognition  that  this  was  an  abort-mission  situaritm.  From 
recognition  of  the  critical  point  at  50.45  seconds  into  die  mission,  it  took  approximately 
6.55  seconds  to  recognize  that  diis  was  an  undesirable  situation.  The  change  in  the 
maneuvering  status  and  subsequent  overall  assessment  of  the  mission  resulted  in  a  time 
of  propagation  ci  0.14  seconds. 

Scmiario  three  involved  a  vehicle  control  system  failure.  After  passing  sevoal 
waypoints,  the  AUV  experienced  an  electrical  failure  of  the  diving  planes.  The  first 
result  was  a  failure  of  maneuvering  status  because  that  was  the  more  specific  rule.  The 
control  system  failure  rule  fired  shortly  after  that  leading  to  an  overall  mission 
assessment  that  this  was  an  abon  situation.  From  the  instantiation  of  the  triggering 
event  until  the  time  it  was  recognized  as  an  abort  situation  was  an  interval  of  0.24 
seconds.  Prc^gatitm  of  the  maneuvering  status  or  equipment  status  to  the  overall 
missicm  assessor  is  difficult  to  absolutely  determine  because  of  the  fiun  that  both 
maneuvering  assessment  and  equipment  status  assessment  fired.  Either  one  could  have 
caused  the  overall  mission  status  to  change.  Because  of  the  high  salience  of  both  rules, 
activation  of  the  overall  missitm  assessor  occurred  only  0.17  seconds  after  the 
equipment  status  assessment  rule  fired. 

Scenario  four  evaluated  both  some  obstacle  avoidance  and  environmental 
phenomena.  Only  two  obstacle  encounters  were  realized,  resulting  in  only  minor 
deviations  to  die  planned  navigational  track.  A  significant  environmental  phenmnena 
was  simulated  by  having  readings  in  all  three  environmental  senscnrs  exceed  allowable 
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limits.  This  resulted  in  a  mission  abort  Fnmi  the  time  of  the  triggering  event  until  the 
recognition  by  the  mission  assessor  diat  it  was  an  abort  ntuation,  0.56  sectmds  elapsed. 

Scenario  five  tested  multiple  equipment  huluies.  The  AUV  passed  tiuou^ 
sevmal  waypmnts  missing  only  out  time  constraint  A  sonar  failure  (forward  stmar)  led 
to  a  reduction  in  the  overall  missitm  status  to  ConHnue_wiA_Restrictions  as  the  sonar 
went  to  a  critical  state.  A  secmid  sonar  (port  sonar)  led  to  a  reinforeemmit  of  diat  state. 
Failure  of  the  rudder  finally  led  to  the  AUV  surfacing  and  energiang  its  transponder. 
From  the  triggering  event  until  the  decision  to  abort,  0.47  seconds  ekqrsed. 

E.  EVALUATION 

Gxnparison  of  results  reveals  that  propagation  of  status  from  the  furrctional  area 
assessors  to  the  overall  mission  status  assessor  will  probably  meet  real-time  ctmstraints 
in  the  relatively  slow-moving  environment  of  the  AUV  in  its  testing  facility.  The  true 
time  dependency  does  qrpear  to  be  in  the  low-level  action  or  assessment  rules. 
Situation  recognititm  depends  on  good  heuristics.  Using  an  artificial  neural  paradigm 
in  which  assessment  rules  were  placed  (mi  the  agenda  more  quickly  based  on  previous 
assessment  rule  firings  (and  dynamic  salience)  did  not  iqrpreciably  increase  the  speed 
with  which  propagation  of  the  state  occurred.  In  fact,  in  at  least  one  situation  die 
IHopagation  speed  was  slowed  by  0.5  seconds. 

The  use  of  a  layered  situation-based  reasoning  system  a^iears  to  be  sound.  By 
using  an  intermediate  level  assessment  rule,  die  desired  rqiid  reaction  can  be  taken  at 
die  low-level  and  the  assessment  of  functional  state  can  proceed  at  the  same  time. 
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Thus,  diere  need  not  be  a  salience  assigned  to  every  level.  This  tends  to  diminish  the 
benefit  of  a  rule-based  system.  While  it  does  not  appear  to  work  well  in  this 
implementation,  a  dynamic  salience  may  be  beneficial  to  focus  on  desired  reactions 
when  the  Missitm  Executor  is  interfaced  with  an  updated  version  of  the  Guidance 
system  which  can  handle  interrupt  commands.  Refinement  of  heuristics  will  certainly 
be  necessary  to  further  qitimize  the  rule  base. 


t 
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m  CONCLUSION  AND  RECOMMENDATIONS 

A.  SUMMARY  OF  RESULTS  AND  CONTRIBUTIONS 

1.  A  Prototype  Expert  System  for  Mission  Execution 

A  small  prototype  has  been  dedgned,  implemented,  and  tested  for  several 
scenarios.  While  not  all  possible  scenarios  could  be  tested,  experience  in  testing  and 
debugging  the  Mission  Executor  implemented  in  CLIPS  version  5.0  illustrates  the  n^nd 
prototyping  capabilities  diat  are  available  and  die  great  utility  of  objects  to  represent  the 
onboard  systems.  Rules  for  newly-envisitxied  situations  can  be  added  with  relative 
ease.  Thus,  the  prototype  is  easily  extensible. 

2.  Software  Architecture  for  Mission  Execution 

The  hierarchical  structure  designed  has  a  recognizable  data  flow.  The 
incotporatitm  of  die  status-lock  feature  by  using  die  undifnde  comnumd  to  freeze  a 
mission  state  and  prevent  stateAule  collision  is  an  effective  tool  for  extension  in  odier 
areas.  Status  lock  can  be  an  effective  tool  for  debugging  other  types  of  programs  in 
which  a  final  overall  state  must  be  maintained  while  other  final  Iowa-  level  actitms  are 
executing. 
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3.  Detenniiiation  of  Guidance  Ditemipt  Commands 

An  initial  attempt  at  defining  Guidance  intemipt  commands  has  bemi 
accomplished  and  will  subsequently  be  refined  widi  more  experience  in  submarine 
maneuvering. 

4.  Identification  of  New  Data  Flow  in  the  Baseline  System 

The  alnlity  of  die  Executor  to  get  furdim'  navigation  updates  after  a 
collision.avoidance  maneuver  which  takes  it  fitxn  the  desired  pad)  indicates  a  new 
possible  on-demand  data  flow  fimn  the  Navigator  to  the  Executor.  Further,  it  tq^^-^^ars 
reasonable  diat  Guidance  should  provide  some  kind  of  confirmadon  diat  it  has  earned 
out  an  interrupt  command. 

B.  FUTURE  WORK 

Research  into  a  configurable  mission  executor  has  several  areas  for  extension. 
This  missiem  executor  implementation  is  reliuively  immature,  and  finther  experience  in 
small  underwater  vessel  missions  will  allow  for  greater  refinement  of  its  rule  base. 

1.  Mission  Executor  Portability 

The  Mission  Executor  has  several  modes  in  udiich  it  can  reside  onboard  die 
GESPAC  computer.  As  mentioned  in  Ouster  m,  a  CLIPS  executable  module  can  be 
created  by  changing  various  flags  in  the  CLIPS  C  language  source  code  and 
recompiling  die  Executor  qiplication.  Another  possible  alternative  is  to  embed  the 
Executor  qiplication  in  a  large  shell  program  which  would  hold  all  of  die  modules. 
While  die  two  previous  suggestions  would  result  in  a  smrage  savings,  the  best  solution 
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for  die  Executor  is  to  port  die  endxe  CLIPS  interpreter  (with  die  exception  of 
develo|»nent  tocds)  to  die  onboard  computer.  This  will  allow  for  greater  flexibility  in 
die  form  of  use  of  the  build  and  eval  functions  to  construct  rules  as  the  mission  is  in 
progress. 

The  build  and  eval  fiinctitms  can  be  very  useful  in  coercing  die  AUV  to 
"learn”  about  difEunilties  encountered  akmg  the  designated  track.  A  collective  decisions 
rule  can  be  invdted  to  analyze  all  of  die  dedsimis  made  thus  far  (previously  archived 
in  die  decision  objects). 

2.  Intcrfadng  the  Executor  to  Dependent  Modules 

Althou^t  interfaces  to  the  various  dependent  modules  are  discussed  to  some 
extent  in  Chapter  IV.  some  of  the  interfaces  will  remain  hypothetical  until  all  of  die 
dependent  modules  are  completed.  Naturally,  incorporation  of  the  executor  into  die 
overall  system  will  require  that  a  comprehensive  system  alteration  plan  be  developed. 
The  CUPS-to-Ada  and  constructs*to-c  external  interfaces  need  to  be  (tefined. 

3.  Pditing  the  Executor  to  the  AUV  n  Graphical  Simulator 

As  die  offboard  mission  planner  is  completed,  the  actual  pmting  of  CLIPS 
source  code  to  the  updated  AUV  n  simulatcxr  will  take  place.  While  diis  in  itself 
shouhl  not  be  tremendously  difficult,  methods  of  simulating  casualties  visually  on  the 
IRIS  machine  need  to  be  develq^  so  duu  SKIITER  can  give  a  more  intuitive 
rqirmentation  of  its  abilities. 
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4.  Incorporation  of  Specialized  Mission  Rules 

At  present,  the  AUV  (q)erates  in  a  ccmstrained  testing  envinmnient,  die  Naval 
Postgraduate  School  swimming  pool  Research  for  some  time  to  c(»ne  will  focus 
primarily  cm  transit,  avddance  of  obstacles  and  other  hazards,  vision  and  sonar  sensing, 
and  safe  return  the  vehicle.  Eventually,  the  vehicle  will  be  able  to  carry  (Hit  a  very 
basic  mission  such  as  deploying  a  camera  <«  a  hydrographic  instrument  for  a  specified 
period  of  time.  Many  possible  AUV  missions  are  elaborated  in  (Macnmson,  1988). 
Rules  need  to  be  incoiporated  for  the  situations  described  in  that  research  which  cover 
casualties,  envirxmmental  degradations,  and  obstacles,  all  of  which  could  hinder  m 
hazard  the  specialized  mission. 
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APPENDIX  A.  MISSION  EXECUTOR  SOURCE  CODE 


Prograamer 

System 

Program 

Functional  Area 
Latest  Revision 


N  P  Wilkinson 
CLIPS  5.0 

AUV  Mission  Executor  "Skipper" 
Main  Program 
21  August  91 


Description 

The  AUV  Mission  Executor  Systwt.  This  aiodule  skipper. dp 
is  the  Bialn  program  to  which  all  of  the  other  five  modules 
are  subordinate.  The  highest  reasoning  level  (overall  aiisslon 
assessment)  as  well  as  utility  rules  for  saving  decisions 
reside  here.  Event  management  is  also  controlled  here.  A  continuous 
loop  checks  for  termination  events  which  shutdown  the  Mission 
Executor. 

This  software  incorporates  the  use  of  the  following  in  the 
"layered  worlds"  paradigm: 

—  Use  of  Fuzzy  Logic 

—  Prioritization  of  inportant  actions  and  state  assessment 

—  Truth  Maintenance  via  CLIPS  logical  constuct  and  "status  lock* 


Global  variables  which  pertain  to  main  module  or  to  all  ; ; 
parts  of  the  program.  For  the  most  part  the  actual  values  ; ; 
are  unlnqportant  to  understanding  of  the  program.  ; ;  < 


(defglobal  ?"start_time*  - 

?*mission_time"  “ 

?*mission_degradation_time*  «• 
?*recovery_time*  - 

?*Time_Interval*  ■ 

?*emergency_sallence*  - 

?*mission_critical_power*  « 
?*Functlonal_area_f allure"  ■ 
?*Functional_area_critical*  ■ 
?*current_event*  ■ 

?"Goalx* 

?"Goaly* 

?*Goalz* 


0. 

0 

0. 

30.0 

20.0 

1000 

30.0 

0 

0 

1 

0.0 
0.0 
0.0  ) 


99 


»  9 


; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;;;;;;;;;; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 

Function  show-dano-doserlption 
Function  which  shows  the  user  a  selection  of  scenarios. 

It  is  by  no  means  all-enconpassing.The  55  rules  which  make 
up  this  system  can  be  permuted  to  build  many  scenarios 


(def function  show-demo-description  () 

(printout  t  crlf  crlf  crlf  crlf  crlf  crlf) 

(printout  t  "  Welcome  to  the  MISSION  EXECUTOR  DEMO  ") 

(printout  t  crlf  crlf  ) 

(printout  t  "WAYPOINTS:  All  scenarios  take  place  over  the  same  set" 

crlf 

"  of  INITIAL  waypoint  coordinates."  crlf  crlf) 

(printout  t  "EQUIPMENT:  All  equipment  is  simulated  in  the  event 

file-  crlf 

"  Objects  are  created  for  each  onboard 

equipment"  crlf  crlf) 
(printout  t  "SITUATIONS:  All  situations  are  also  simulated  in 

the  event"  crlf 

"  file.  For  instance,  an  obstacle  detection 

is  "  crlf 

"  listed  and  this  simulates  the  Obstacle 

Avoidance"  crlf 

"  DecisionMaker  passing  this  information 

through"  crlf 

"  the  interface  to  the  Executor  .  "  crlf  crlf) 

(printout  t  "SCENARIO  CHOICES:  select  number  <Ret>"  crlf 
"1  Naypoint_Hopping  Only  (transit) "  crlf 
"2  Obstacle  Avoidance  "  crlf 

"3  Vehicle  Control  System  Failure"  crlf 

"4  Obstacles  and  Environment  Problems  "  crlf 

"5  Equifanent  Failures  "  crlf 

*€  Exit  the  Simulator  "  crlf  crlf  crlf) ) 


;  Decision  objects  and  functions  of  possible  use  in  a  machine 
;  learning  program.  The  decision  can  be  archived  in  an  object. 

;  Most  iaqportantly,  the  decisions  made  in  the  system  are  output 
so  that  a  future  developer  can  see  the  propagation  of  changes 
;  in  decisions. 


9  0  0  9 


This  copies  the  current  data  in  the  current  decision  to  a 
a  storage  object 


(deffunction  copy-old-instance  (?instance) 

(send  (symbol -to-instance-name  ?instance)  put-type 
(send  [current]  get-type  )) 

(send  (symbol-to-instance-name  ?instance)  put-level 
(send  [current]  get-level)) 

(send  (symbol-to-instance-name  ?instance)  put-action 
(send  [current]  get -action) ) 

(send  (symbol-to-instance-name  ?instance)  put-decision_time 
(send  [current]  get-decision_tiiiie) ) ) 


(defclass  DECISION  (is-a  USER) 
(slot  type  ) 

(slot  rule) 

(slot  level) 

(slot  action) 

(slot  decision  time) ) 


;  This  routine  creates  the  decision  objects  and  also  puts  out 
;  the  propagation  trail 


(deffunction  decision-change  (?the_type  ?the_rule  ?the_level 
?the_action) 

(bind  ?naine  (gensym*)) 

(bind  ?the_time  (-  (time)  ?*start_time*) ) 

(make-instance  ?name  of  DECISION) 

(copy-old-instance  ?name) 

(send  [current]  put -type  ?the_type) 

(send  [current]  put-rule  ?the_rule) 

(send  [current]  put-level  ?the_level) 

(send  [current]  put -action  ?the_action) 

(send  [current]  put-decision_time  ?the_time) 

(printout  t  crlf  "»»»»»»  Decision  ««««««  "  crlf 


"  type 

"  ?the_type  crlf 

"  rule  ; 

"  ?the_rule  crlf 

• 

"  level 

"  ?the_level  crlf 

"  action  ; 

"  ?the_action  crlf) 

(format  t 

"  time  ; 

%6.3f%n%n"  ?the_t 
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;;;;;;;;;;;;;;;  Bvant  (Aj«cts  and  Haodlar  s t } i ! t f i t } } } ; i i i ; i i : i > 
;  Evants  ara  aodalad  aa  objacta  with  a  nuaibarr  daacrlption,  ;; 
;  and  time.  Tha  avant  daacription  and  time  ara  output  aa  thay  ;; 
;  ara  procaaaad  for  axacution.  ;; 


(dafclaaa  EVENT_SCHEDULE  (ia-a  USER) 
(alot  avant_no) 

(alot  avant_time) 

(alot  event_action) 

(alot  daacription) 
(meaaaga-handlar  axacuta-avant) ) 


(dafmeaaaga-handlar  EVENT_SCHEDULE  axacuta-avant  primary  () 

(aval  ?8alf :avant_action) 

(printout  t  crlf  «***<>*****••************************************•• 

crlf 

"  Event  Number  :  "  ?8elf :event_no  crlf 

" _ ■  crlf 

*  Deacription  :  "  ?aelf: daacription  crlf 


(format  t 
(printout  t 


crlf) 

"  Time  %6.3f%n”  ?8elf: event jtime  ) 

«•*********•*************************************" 


crlf) 


(bind  7*current_event*  (+  ?*current_event*  1))) 


Navigation  waypoint  poature  objecta 


(defclaaa  POSTURE  (ia-a  USER) 
(alot  configuration) 

(alot  action) 

(alot  number) 

(alot  xjpoa) 

(alot  y_po8) 

(alot  z_j>o8) 

(alot  theta  ) 

(alot  ETA) ) 
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;;  Functions  to  simulate  Guidance  receiving  connands 

; ; ; ; ; ; ; ; ; ; ; ; ; ;  Guidance  is  a  dumov  siodule  ;;;;;;;;;;;;;;;;;;; 

(deffunction  Call -Guidance-Waypoint  (?destination) 

(assert  (Guidance  receive-waypoint) ) 

(printout  waypoint  ?destination) ) 

(deffunction  Call-Guidance-Conmand  (?action  ?object -equipment) 
(assert  (Guidance  receive-coanand) ) 

(assert  (Current_actlon  ?actlon  ) ) 

(assert  (show  board) ) 

(printout  action  ?action  "  "?object -equipment  crlf ) ) 


(deffunction  Replan-Route  (?action 
?goalx  ?goaly  ?goalz) 

(do-for-all-instances  ((?posture  POSTURE))  ;get  rid  of  old 

TRUE  ;  waypoints 

(send  ?posture  delete) ) 

(assert  (waypoint  0) ) 

(assert  (vehicle  operational)) 

(assert  (current_plan  "replan.dat")) 

(assert  (Current^action  replanning) ) 

(assert  (upload  plan) ) ) 


(deffunction  Abort -Route  () 

(do-for-all-lnstances  ((?posture  POSTURE))  ;get  rid  of  old 

TRUE  ;  waypoints 

(send  ?posture  delete  ) ) 

(assert  (waypoint  0) ) 

(assert  (vehicle  operational) ) 

(assert  (currentjplan  "abort. dat ”) ) 

(assert  (Current_action  transiting_to_abort_rendezvous) ) 
(assert  (upload  plan) ) ) 
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; ; ; ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; 

;  SystMi  Initialisation  ; ; ; ; 

tsstpsssssissttsiississtfststsssiiitittsssfsstsittsiffiisfssttsssissit 

;  The  rules,  initial  facts  and  initial  object  instances  which  are  ;;; 

;  present  at  the  start  of  execution  .  ;;; 

f»S$0tiifiSti9t$i»iSS$S$$0090»000»S$iS9S9iSS»t90»t$iit§i9$if99$9f$SS7 


(definstances  STARTXllG_DECZSXOMS 

(current  of  DBCXSXW  (type  Overall) 

(rule  Hone) 

(level  Hi^) 

(action  Pierside) 

(docision_tlaw  (tia»)))) 

;;;;;  After  the  vehicle  is  cheeked  for  operational  status  by  the 
the  siovsaisnt  of  a  control  surface,  it  is  assused  to  be 
;;;;;  operating  under  ideal  conditions 


(deffacts  Starting_Facts 

(Overall_adssion^status  Continue^unxestrieted) 
(configuration  transit) 

(Bqui|Msant_8tstus  noxsMl) 

(Maneuvering_8tatus  unrestricted) 
(Environswntal^StatttS  nozsMl) 
(Navigation^Status  within^telerance) 

(Spec  Mission  Status  feasible)) 


;;;;  Opens  the  siaailatlon  data  files  which  adadc  the  andules  which 
;;;;  will  interface  to  the  Executor.  This  does  not  include  the  equipment 
;;;;  aonitoring  interface  which  is  shown  in  sensor. dp 


(defrule  initialise-vehicle 
-> 

( show'desm -description ) 

(bind  ?scenario  (read) ) 

(if  (and  (>*  ?scenario  1)  (<-  ?scenario  5))  then 

(bind  ?scenariofile  (str-cat  "scenario"  ?scenario  ".ins")) 
else  (if  (-  ?scenarlo  €)  then  (halt) 

else  (printout  t  "Xnproper  Selection  —  Please  Choose  1-6"  crlf 

crlf) 

(retract  *) 

(assert  (initial-fact) ) ) ) 

(load-instances  ?scenariofile) 

(assert  (vehicle  operational)) 

(assert  (waypoint  0) ) 

(open  "6uldance.dat"  waypoint  "w") 

(open  "Conaand.dat"  action  "w") 
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(open  "obstacles.dat"  obstacles  *r") 
(assert  (current_plan  "nisslon^plan.dat") ) 
(assert  (upload  plan) ) 
(set-salience-evaluatlon  every-cycle) ) 


Starts  the  vehicle  reasoning  system 
Loads  up  the  mission  reference  postures  into  objects. 

(defrule  upload 

(vehicle  operational) 

?current  <-  (currentjplan  ?file) 

(waypoint  ?no) 

?upload  <- (upload  plan) 

-> 

(if  (-  ?*start_tlme*  0.)  then 
(bind  ?*start_time*  (time) ) ) 

(open  ?file  plan  "r") 

(bind  ?number  ?no) 

(bind  ?confi9  (read  plan)) 

(while  (neq  ?confi9  EOF) 

(bind  ?naine  (gensym*)) 

(make>lnstance  ?narae  of  POSTURE 
(configuration  ?conflg) 

(action  unlcnown) 

(number  ^number) 

(x_pos  (read  plan)) 

(y_pos  (read  plan)) 

(z _pos  (read  plan)) 

(theta  (read  plan)) 

(ETA  (read  plan))) 

(bind  ?conf ig  (read  plan) ) 

(bind  ?niniber  (■•■  1  ?number) ) ) 

(close  plan) 

(retract  ?current) 

(retract  ?upload) 

(assert  (waypoint -status  mark_on_top) ) 

(assert  (aiission_timer  running) ) 

(assert  (Current_action  underway))  ) 


lOS 


Timr  Control  (Program  Loop] 

Continually  Loops  whlla  tha  vahicla  is  In  operation 
Blnda  the  mission  time  to  the  CPU  clock 


; 


(defrule  Mission_Timer 
(declare  (salience  -500) ) 

?timer  <-  (mlssion_timBr  running) 

-> 

(bind  ?*aiiasion_tiam*  (-  (time)  ?*start_tlme*) ) 

(if  (and  (neq  ?*mission_degradation_tlam*  0.) 

(>  ?*sd.sslon_time*  ?*Bdsslonjdegradation_tiam* 

?*recoveryjtia»*) ) )  then 
(assert  (recovery_evaluatlon  poor) ) 

(bind  ?*mlssion_degradatlon_tim*  0.)) 

(retract  ?tiB«r) 

(assert  (timer-flag  on))) 


(defrule  timar-sianager 
?tiswr-flag  <-  (timer-flag  on) 

-> 

(retract  ?timer-flag) 

(assert  (mission_timer  running) ) 
(assert  (system_B»nitors  running) ) 
(assert  (schedule_event  next_event)) 
(assert  (avoidance__time_check) ) 
(assert  (document  siission) ) ) 


;;;  Mission  Oocuawntation  ;; 


(defrule  Oocument_Nission 

7documsnt  <-  (docuaiant  adssion) 

-> 

(if  (>  ?*8d.sslon__time*  ?*Tiais_Znterval*)  then 
(save-instances  "Mission_Log . ins” ) 

(save-facts  "Mission_Log. facts”) 

(bind  ?*Tia»_lnterval”  (♦  ?*Tia»__lnterval*  20.0)))  ;  sets 
(retract  ?document))  ;time  interval  for  gathering 

;  log. data 
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Event  Manager/Scheduler 


Check  EVENT^LIST  for  events  where  ati88ion_tliiie  has  already 
exceeded  event_tline  and  put  it  on  the  schedule. 


(defrule  event_schedule_nanager 
(declare  (salience  -500)) 

?event  <-  (schedule_event  next_event) 

->  ” 

(do-for-instance  ((?event  EVENT_SCREDULB) ) 

(and  (<  ?event:event_tiaie  ?*aii88ion_tiine*) 
(eg  ?event:event_no  7*current_event*) ) 

(send  ?event  execute-event) ) 

( ret  ract  ?event ) ) 


; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;  Function  Total -Functional- 
Problems  ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;;;;;; ; ; 

; ; ; ;  This  tabulates  the  problems  of  the  various  functional  areas . 

f  0  0 


(deffunction  Total -Functional-Problems  (?overall) 

(if  (>-  ?*Functional_area_failure*  1)  then 
(retract  ?overall) 

(assert  (Overall__mi88ion_8tatus  Abort_mission) ) 
(assert  (propagate-change  down) ) 

(decision-change  Overall_Mi8sion  C>verall_Mi8sion_Asse8sor  High 
Abortjmission) 
else 

(if  (and  (eq  ?*Functional_area_failure*  0) 

(>  ?*Functional_area_critical*  2) )  then 
(decision-change  Overall_Mi8sion 
0verall_Mi88ion_Assessor  High  Abortjmission) 
(retract  ?overall) 

(assert  (0veralljmi88ion_status  Abort  mission) ) 
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(assert  (propagate-change  down) ) 
else 

(  if  (and  (eq  ?*Functional_area__£allure*  0) 

(neq  ?*Fimctlonal_area_crltlcal*  0) )  then 
(retract  ?overall) 

(assert  (C)verall_mlsslon_status  Contlnuejwith^Restrlctlons) ) 
(decision-change  Overall_Nlssion  Overall_Mission_Assessor 
High  ContinueMission_wlth_restrictlons) ) ) ) ) 


; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;  Overall  Mission  Status  ;;;;;;;;;;;;;; 
;  This  waits  on  changes  to  the  5  rule  areas  Changes  from 
;  these  are  indicated  with  the  assertion  of  the  propagate_ 

;  change  flag.  Changes  to  functional  areas  are  checked  for 
;  effect  to  the  overall  mission  by  the  function  Total- 
;  functional  Problems. 


(defrule  Overall_Mission_Assessor 

?overall  <-  (Overall_mission_status  ?status) 

?equip  <-  (Equipment_Status  ?ecpaipment_status  ) 
(Maneuvering_Status  ?maneuver_status  ) 

(Navigation_Status  ?nav_status  ) 

(Envlronmental_Status  ?environment_status  ) 

(Spec__Mlssion_Status  ?specmission__status  ) 

?change  <-  (propagate  change) 

•> 

(retract  ? change) 

(if  (eq  ?equipaient_status  ma jor_failure)  then 

(bind  ?*Functional_area_failure*  (+  ?*Functlonal_area_failure* 

else 

(if  (eq  ?equipment_status  equipaient_crltical)  then 
(bind  ?*Functional_area_critical* 

(+  ?*Functional__area_critical*  1) ) ) ) 

(if  (eq  ?maneuver_status  severely_restricted)  then 
(bind  ?*Functional_area_failure* 

(■!■  ?*Functional  area  failure*  1)) 


else 

(if  (eq  ?maneuver_status  restricted)  then 
(bind  ?*Functional_area_critical* 

(+  ?*Functional_area_critical*  1)))) 

(if  (eq  7nav_status  out_of_tolerance)  then 
(bind  ?*Functional__area_failure* 

(+  ?*Functional  area  failure*  1)) 


else 

(if  (eq  ?nav_status  critical)  then 
(bind  ?*Functional  area  critical* 
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(+  ?*Functional_area_critical*  1)))) 

(if  (eq  ?envitoranent_status  ma jor_deviation)  then 
(bind  ?*Functional_area_failure* 

(+  ?*Functional_area_£ailure*  1)) 

else 

(if  (eq  ?environment_status  critical^deviation)  then 
(bind  ?*Functional_area_critical* 

(+  ?*Functional_area_critical*  1)))) 

(if  (eq  ?specinission_status  infeasible)  then 
(bind  ?*Functional_area_failure* 

(+  ?*Functional_area_failure*  1))) 
(Total-Functional-Problems  ?overall) ) 


Default  Status  for  start  of  mission  and  when  the  status 

t  t  0 

0  0 

is  restored  to  normal  after  a  recovery  from  mission 

0  0 

restrictions 

0  0 

0  0 

(def rule  Continue-Mission_unrestricted 
(logical  (Equipment_Status  normal) 

(Maneuvering_Status  unrestricted) 

(Environinent_Status  normal) 

(Navigation_Status  within_tolerance) 
(Spec_Mission_Status  feasible) ) 

■> 

(decision-change  Overall_Mission  Continue-Mission_unrestricted 
High  Continue-mission-with-no-restrictions) 

(assert  (Overall  mission  status  Continue  Unrestricted) ) ) 


; ; ; ; ; ; ; ; ; ; ; ; ; ;  Restricted  Status  Update  ; ; ; ; ; ; ; ; ; ; ; ; ; ; 

If  the  recovery  evaluation  is  poor  (as  determined  by 
by  exceeding  a  standard  recovery  time)  then  abort  the 
mission  . 


(def rule  Continue-mission_restricted-update 

(Overall_mission_status  Continue_with_Restrictions) 
(recovery_evaluation  poor) 

-> 

(decision-change  Overall_Mission  Continue-mission_restricted-update 
Assessment  AbortJHission) 

(assert  (Overall_mission  status  Abort  Mission) ) ) 
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; ; ; ; ; ; ; ; ; ;  Initial  Rastrictad  Status  Actions  ;;;;;;;;;;;;; 
;  Note  the  inission_da9radation  status  ;;; 


(defrule  Continue_iQission_rastrictad_initial 

(Ovarall_mission_status  Continua_with_Rastrictions) 

-> 

(decision-change  Overall_Mission 

Continue_aiission_rastricted_initial 
Assessment  Note-time-of-status-change) 

(bind  ?*inission_degradation_time*  (-  (time)  ?*start_time*) ) ) 


; ; ; ; ; ; ; ; ; ; ; ; ;  Abort  Mission  ;;;;;;;;;;;;;;;;;;;;;;;;; 
A  mission  abort  causes  the  overall  mission  status  to  ; ; 
be  locked.  A  replan  must  be  made  to  reach  the  ; ; 
abort  rendezvous  ;; 


; ;  Default  is  that  AUV  can  return  under  ovn  power  after 
;  a  mission  abort.  However,  if  there  is  a  primary  control 
;  system  failure  such  as  failure  of  rudders  or  dive-planes, 
;  the  vehicle  will  require  recovery. 


(defrule  Abort_Mission 
(declare  (salience  500)) 

(Overall_mission_status  Abort_mission) 

?change  <-  (propagate-change  down) 

?point  <-  (waypoint  ?no) 

-> 

(retract  ?point) 

(retract  ?change) 

(decision-change  Overall_Mission  Abort_Mission  Ik>w 

lock_status_and_replan_route_^to_abort_rendezvous) 

(undefrule  Overall_Mission_Assessor)  ;  status  lock 

(do-for-instance  ((?control  CONTROL_SYSTEM) ) 

(and  (eq  ?control: status  INOPERATIVE) 

(neq  ?control  Hover-Thrusters) ) 

(progn  (Call-Guidance-Command  turn_on__transponder  transponder) 
(Call-Guidance-Comroand  ascend_surface  planes) 

(printout  t  crlf  crlf  "»»>  Shutting  Down  for  Dynamic  Recovery 

«<"  crlf 

’’>»»  Transponder  will  function  for  2  hours 

«<"  crlf) 

(halt))) 

(Abort -Route  ) ) 


no 


Function  Display-Status  ; ; 

Actually  prints  the  status  display.  ;; 


(def function  display-status  (?waypoint  ?status  Tmaneuvering  ?navigation 
?environinent  ?equipment  ?mission 

?action  ?depth-configuration  ?con£iguration  ) 

(bind  ?display-time-minutes (trunc  (/  ?*inission_tiine*  60.0))) 

(bind  ?display-time-seconds  (round  (mod  ?*inission_tiiae*  60.0))) 

(if  (  <  ?display-time-seconds  10.0)  then 
(  bind  ?display-time-seconds  (str-cat  "O"  ?display-tiine-seconds) ) ) 
(printout  t 


crlf 

Skipper's  Display  I"  crlf 


TIME  in  min  secs 


?display-time-minutes 
?display-time-seconds  crlf 

crlf 


Overall  Mission  Status 

»» 

"  ?status 

"  «« 

n 

Manuevering_Status 

n 

?maneuvering 

crlf 

« 

Equipment_Status 

■t 

?equipment 

crlf 

n 

Navigation_Status 

ft 

?navigation 

crlf 

ft 

Envi  roninent_status 

ft 

?envlroninent 

crlf 

ft 

Spec_Mission_status 

ft 

Tmission 

crlf 

evolution 

depth-status 


?configuration  crlf 

?depth-configuration  crlf 


"I 


•r  crlf 


crlf 


Iiast  Command  to  Guidance 
enroute-waypoint 


?action  crlf 
?waypoint  crlf 


"I 

^mm 

'I 


Direction 


Obstacles 

Proximity  |  Type 


■  "  crlf 
I"  crlf 
'  "  crlf 
I"  crlf 


crlf) 


(do-for-all-lnstances  ((?obstacles  OBSTACLE)) 

(eq  ?obstacle : colllsion_danger  YES) 
(printout  t  "  "  ?obstacle: bearing  "  " 

?obstacle: proximity  "  " 

?obstacle : type  crlf  crlf)) 


111 


(printout  t  "  crlf 

"I  EQUIPMENT  DOWN  |"  crlf 

n - .  crlf) 


(do-for-all-instances  ( ( ?equipnnent  SYSTEM_MONITOR) ) 

(eq  ?equipinent :  status  INOPERATIVE) 

(printout  t  "»»»»  *  (instance-nane-to-symbol  Tequlpoent) 

"««««  "  crlf) ) ) 


Show  Status  Board 

Shows  the  status  of  vehicle  worlds  and  actions  being  taken 
to  offset  deviations  or  discrepancies.  Mot  as  tliaely  as 
propagation  flow  of  decisions,  this  only  shows  the  effects 
of  a  decision  since  the  last  low  level  conniand  to  Guidance 


(defrule  show_status_board 

(Overall_mission_status  ?status) 

(Maneuvering_Status  Tmaneuvering) 

(Navigatlon_Status  ?navigation) 

(Environinental_Status  ?environnvent ) 

(Equipment_Status  ?equii»nent) 

(Spec_Mission_Status  ?mission) 

(waypoint  ?nuinber) 

?current  <-  (Current_action  ?action) 

?show  <-(show  board) 

-> 

(do-for-instance  ((?point  POSTURE)) 

(eq  ?point : number  (-  ?nuinber  1  )) 

(progn  (bind  ?depth-configuration  ?point : action) 

(bind  ?configuration  ?point: configuration) ) ) 

(display-status  ?number  ?status  ?maneuvering  ?navigation 
?environinent  ?equipnient  mission  Taction 
Tdepth-configuration  Tconflguration) 

(retract  Tcurrent) 

(retract  ?show) ) 


End  of  Main  Module 
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Programmer  :  H  P  Wilkinson 

System  CLIPS  5.0 

Program  AUV  Mission  Executor  "SKIPPER" 

Functional  Area  Navigation 

Latest  Revision  :  30  August  91 

$  s 

Description 

/  0 

This  area  covers  the  navigational  situations  which  require  a 
higher  level  of  reasoning  than  can  normally  be  found  in  the 
Navigator  Module.  Covers  special  navigational  situations  such 
as  diving,  surfacing,  ascending  to  safe-depth,  and  more 
mundane  situations  such  as  passing  waypoints. 


$00000000000000000000000000000000000000000000000000000000000 
; ; ; ;  Global  Variable  Declarations  Pertaining  to  Navigation; 
000000000000000000000000000000000000000000000000000000000000 


(defglobal  ?"QtyNavProblema*  “  0 

?*NrNavInstrumentsfailed*  “  0 

?*NrBottomObstacles*  ■  0 

?"navigation__aalience*  -  100 

?"safe_depth*  ■  3 

?*BottomObstacleTime"  *0.0 

?*bottom  obstacle  time  interval*  ••  10.0) 


Navigation  Status  Assessment 


(defrule  Navlgation_Assessment 

(declare  (salience  ?*navlgation_salience*) ) 

(or  (Depth_Status  Shoaling) 

(Time_Deviation) ) 

?nav  <-  (Navigation_Status  ?navstatus) 

■'  -> 

(decision-change  Navigation  Navigation_Assessment  Assessment 

determine_Nav_Status_and__pass_to_Overall_Mission_assessor) 
(bind  ?*QtyNavProblems*  {+  ?*QtyNavProblems*  1)) 

(if  (or  (>«  ?*QtyNavProblems*  4) 

(>  ?*NrNavInstrument8failed*  2))  then 
(retract  ?nav) 

(assert  (Navigation_Status  out_of_tolerance) ) 

(assert  (propagate  change) ) 
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PPPUPL't''  1^1)1 


else 

(If  (or  (-  ?*QtyNavProbl«iis*  2) 

(-  ?*NrNavInstruiiientsfailed*  2) )  then 
(retract  ?nav) 

(assert  (Navigation_Status  critical)) 

(assert  (propagate  change) ) ) ) ) 


; ; ; ; ; ; ; ; ; ; ;  Separate  Equipment  Consideration 

(defrule  Navigation_Asaessinent_Equipment 

(declare  (salience  ?*navigation__salience*) ) 

(Equipment_Failure  HAVIGATlcnTlNSTRUMENT  ?instniment) 

?nav  <-  (Navigation^Status  ?navstatus) 

->  ~ 

(decision-change  Navigation  Navigation_Assess]nent  Assessment 

determine_Nav_Status_and_pass_to_Overall_Mission_assessor) 
(bind  ?*QtyNavProbleins*  (+  ?*(JtyHavProbleins*  1)) 

(if  (or  (>-  ?*QtyNavProbleins*  4) 

(>  ?*NrNavInstrumentsfailed*  2))  then 
(retract  ?nav) 

(assert  (Navigation_Status  out_of_tolerance) ) 

(assert  (propagate  change) ) 

else 

(if  (or  (-  ?*QtyNavProblems*  2) 

(>  ?*NrNavlnstrumentsf ailed*  2))  then 
(retract  ?nav) 

(assert  (Navigatlon_Status  critical) ) 

(assert  (propagate  change) ) ) ) ) 


Although  the  AUV's  propulsion  power  source  is  good  for 
approximately  2  hour  mission,  even  long  testing  facility 
missions  may  cause  an  abort. 


(defrule  Energy_Assessment  * 

(Energy_Devlation  major) 

?status  <- (Navlgation_Status  ?navstatus) 

-> 

(retract  ?status) 

(assert  (Navigation_Status  out_of_tolerance) ) 

(assert  (propagate  change) ) ) 
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; ; ; ;  Waypoint  Arrival  Rules 

9  9  0  9 

; ; ; ;  These  rules  are  invoked  whether  or  not  the  AUV  is  in  an  explicit 
;;;;  exception  situation. They  conpare  depth  and  determine  if  point 
; ; ; ;  is  the  Goal  (origin,  rendezvous  or  abort_rendezvous  point) . 

; ; ; ;  Energy  and  time  are  checked,  possibly  indicators  of  an 
; ; ; ;  implicit  exception  such  as  exceeding  the  estimated  time  of  ; 
; ; ; ;  arrival  (ETA)  ; 

99999999990999090999999999999099999909999909999999999999999999999999 


; ; ;  Recognizes  origin  or  rendezvous  point  as  appropriate 

(defrule  Goal_Recognition 

(waypoint-status  mark_on_top) 

(waypoint  ?waypoint_no) 


(do-for-instance  ((?current  POSTURE)) 

(eq  ?current : number  ?waypoint_no) 

(if  (eq  ?current : configuration  Goal)  then 

(Call-Guidance-Command  arrived^at  rendezvous) 
(printout  t  crlf  crlf  "»»>Made  it  to  (Soal«««<"  crlf 

"  At  time  :  "  ?*mission_time*  crlf) 

(halt) ) ) 

(assert  (conpare-depth) ) ) 


;;;  Upon  waypoint  arrival,  conpares  depth  at  current  waypoint  to  next 
; ; ;  waypoint  to  determine  overall  change 

(defrule  WaypointArrival-DepthConparison-GoalCheck 
?conpare  <-  (conpare-depth) 

?w  <-  (waypoint-status  mark_on_top) 

(waypoint  ?waypolnt_no) 


-> 

(decision-change  Navigation  NaypointArrival-DepthComparison 
Low_assessment  determine_type_ofjdepth_change) 

(retract  Tconpare) 

(retract  ?w) 

(do-for-instance  ( (?current  POSTURE)  (?next  POSTURE) ) 

(and  (eq  ?current : number  ?waypoint_no) 

(eq  ?next :  nundoer  (■<■  ?current :  number  1))) 

(progn  (if  (eq?current:z_pos  ?next:z_pos)  then  (send  (synbol-to- 
instance-name  ?current) 
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put -action  no-depth-change) ) 

(if  (and  (>  ?current : z_po8  ?next:zjpos) 

(neq  ?next : z_pos  0.0))  then 

(send  (symbol-to-instance-nane  ?current) 
put-action  ascent)) 

(if  (and  (>  ?curzent : z_pos  ?next:z_pos) 

(eq  ?next:z_pos  0.0))  then 

(send  (symbol-to-instance-nane  ?current) 
put-action  surface) ) 

(if  (<  ?current : z_pos  ?next:z_pos  )  then 

(send  ( symbol -to-instance-nane  ?current) 
put -action  dive) ) ) ) 

(Call-Guidance-Command  marlc_on_top  waypoint) 

(assert  (delta_depth__check  complete) ) 

(assert  (time-distance-check) ) ) 


(defrule  Haypointjnonitor 
?point  <-  (waypoint  ?no) 

?depth-check  <-  (delta_depth_check  conplete) 

(configuration  ?config) 

■> 

(decision-change  Navigation  Maypoint_monitor  Low__as8essment 
assess_next_waypoint_and__sequence) 

(bind  ?next_point  (+  ?no  1)) 

(retract  ?point) 

(do-for-instance  ( (?destination  POSTURE  )) 

(eq  ?destination: number  ?next_point) 
(Call-Guidance-Naypoint  ?destinatlon) ) 

(retract  ?depth-check) 

(assert  (waypoint  ?next_point) ) ) 


Performs  a  «tiine-distance»  check  if  passing  a  waypoint; 


(defrule  Naypoint_DistanceTlmeEnergy_Check 
(waypoint  ?no) 

?t-check  <- (time-distance-check) 

■> 

(decision-change  Navigation  Naypoint_DistanceTiiiie_Check 

Low_asses8inent  determine^!  f_need_to_increa8e_speed) 
(bind  ?energydepletion  (*  .00013  ?*mission_tlme*) ) 

(if  (>  ?energydepletion  .70)  then 

(assert  (Energy_I>eviation  major) ) ) 
(do-for-instance  ( (?point  POSTURE) ) 

(eq  ?point:nuniber  ?no) 


116 


(if  (>  (abs  (-  ?*nis0ion_time*  ?polnt:ETA))  40.0)  then 
(assert  (Tlne__I>eviation) ) 

else 

(if  (>  (abs  (-  ?*iBission_tiaie*  ?point:ETA))  20.0)  then 
(Call-Guidance-Coanand  Increase-Speed  Drive_8iotors) ) ) ) 

(retract  ?t -check)) 


(<tefrule  TimeJDeviation 
(Time  Deviation) 

-> 

(Replan-Route  none  ?*(3oalx*  ?*Goaly*  ?*Goalx*)) 


Depth  Rules  ; ; ; 

These  rules  require  a  direct  depth-check  from  sonar.  Currently  ;;; 
exceptions  to  correct  bottom  following  are  signalled  by  the  ; ; ; 
emergency  obstacle  flag  ;;; 


(defrule  depth_sounding_deviation_short_range 
(or  (obstacle-flag-emergency  0001) 

(obstacle-flag-emergency  0011) 

(obstacle-flag-emergency  0101) 

(obstacle-flag-emergency  0111) 

(obstacle-flag-emergency  1101) 

(obstacle-flag-emergency  1011)) 

-> 

(decision-change  Navigation  depth_sounding_deviation_shortmg 
low_supervisory  avoid_possible_shoaling) 
(Call-Guidance-Command  ascend-?*safe_depth*  planes) 

(bind  ?*NrBottomObstacles*  (-*-  ?*MrBottofBObstacles*  1)) 
(assert  (Depth-Status  Violation) ) ) 


;  Depth  Sounding  deviation  at  the  liadt  of  sound  sensors 


(defrule  depth_soundlng_devlation_long_range 
(obstacle^alert  on) 

(new_obstacle  on) 

->  ” 

(decision-change  Navigation  depthsounding_deviation_longmg 
low_supervisory  avoid_possible__shoaling_early) 
(do-for-instance  ( (?obstacle  OBSTACLE) ) 
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(and  (eq  ?obstacle:type  bottom) 

(eq  ?obstacle:IO_nuin  ?*obstacle_ref*) ) 


(progn 

(bind  ?*NrBottonObstaclos*  I*  ?*MrBottaaiC»>8tacles*  1)) 
(Call-Guidanco-Coonand  a8cand-?*8afe_dopth*  plan«8) 
(a88ert  (Depth-Statu8  Violation) ) ) ) ) 


; ; ; ;  Aggregate  of  obataclea  over  abort  period  of  time  Indlcatea  the  AW 
; ; ; ;  la  In  a  aerloua  potential  grounding  altuatlon 

(defrule  I>etect_Shoallng 
(Depth-Statua  Violation) 

(teat  (>  ?*NrBottoai0b8tacle8*  1)) 

■> 

(declalon-change  Navigation  Detect_Shoallng  Low^aaaeaaamnt 

detenidne_lf_really_8hoallng_or_ju8t_bottom_ob8tcl) 
(If  (and  (>  ?*NrBottoin0b8tacle3*  4) 

(<  (-  ?*iid.8alon_tl»e*  ?*Bott«n0b8tacleTlme*) 

?*bottom_ob8tacle_tlme_lnterval* ) )  then 
(aaaert  (Depth-Violation  Shoaling) ) 

(Call-Guldance-Coanand  Stop  Drlve-motora) ) 

(bind  ?*Bottoiii0b8tacleTlme*  ?*ml88lon  tine*) ) 


(defglobal  ?*man«uv«r_salittnce*  *  100 

?*obstacle_ref*  -  0 

?*obstacle_cl«arance_tiiiie*  -  30.0 

?*avoidance_tliBe*  «  0. 

?*inan«uverability_factor*  ~  0  ) 


(dafclasa  OBSTACLE  (Is-a  USER) 

(slot  ID_num) 

(slot  typo) 

(slot  bearing) 

(slot  proximity) 

(slot  bm9_drift) 

(slot  time_observ«d) 

(slot  confidence_factor) 

(slot  collision_dan9«r) 

(msssage-tiandlsr  obstacle-change  ) ) 

; ; ; ;  Checlcs  to  see  if  obstacle  is  in  a  180-degree  arc  about  the 
; ; ; ;  )>ow  of  the  sonar 

(def message-handler  OBSTACLE  obstacle-change  prlamryO 
(if  (and  (or  (eq  ?self:confidence_f actor  high) 

(eq  ?self:confidence_f actor  smdlum)) 

(or  (and  (>•■  ?self ibearing  270.)  (<-  7self rbearlng  359.)) 
(and  (<•■  ?self :bearing  90.)  (>-  ?self :bearing  0.))))  then 

(send  ?self  put-collision^danger  YES) 

(assert  (collective_obstacle_assessment) ) 
else 

(send  ?self  put-collision_danger  NO) ) ) 
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; ; ; ;  This  Is  the  functional  area  stq>ervisor  for  saneuvering. ; ; 

(defrule  Maneuvering_Statu8_A8sessBient 
(declare  (salience  ?*Baneuver_salience*) ) 

?ob8t  <-  ((X>8tacle_Avoidance  restricted) 

?a88es8  <-  (Maneuvering-Status-Assess) 

Tnaneuver  <-  (Maneuvering__Status  ?status) 

•> 

(decision-change  Maneuvering  Maneuvering_Statu8_As8e88nent 

maneuvering-assessaant  change-overall-eaneuvering-status ) 
(bind  ?*Baneuverability_f actor*  (+  ?*aaneuverability_f actor*  1)) 
(if  (>  ?*naneuverability_factor*  2)  then 
(retract  Tsaneuver) 

(retract  ?obst) 

(assert  (Maneuvering_Status  8everely_re8tricted) ) 

(assert  (propagate  change) ) 

else 

(retract  Tsaneuver) 

(retract  Tobst) 

(assert  (Maneuvering_Status  restricted) ) 

(assert  (propagate  change) ) ) 

(retract  Tassess) ) 


(defrule  Naneuvering_Statu8_Asses88ant_long_range 
(declare  (salience  ?*aaneuver_salience*) ) 

?ai_ability  <-  (Baneuvering_ability  Tability) 

Tassess  <-  (Maneuvering-Status-Assess) 

Tsaneuver  <-  (Maneuvering^Status  Tstatus) 

■> 

(decision-change  Maneuvering  Maneuvering_Status_A88e8saant 

aaneuvering-assesssant  change-overall-saneuvering-status ) 
(bind  T*aaneuverability_f actor*  (-f  T*Haneuverability_f actor*  1) ) 
(if  (or  (>  T*aaneuverability_factor*  2) 

(eq  Tability  Ma jor^Restriction) )  then 
(retract  Tsaneuver) 

(assert  (Maneuvering_Statu8  severely_restricted) ) 

(assert  (propagate  change)) 

else 

(retract  Tsaneuver) 

(assert  (Maneuvering_Status  restricted) ) 

(assert  (propagate  change))) 

(retract  Tassess) ) 
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(dafrul*  Maneuvering_Equlpment_Failuxe 

(Equipinent_Failure  Control_System  ?control&: (neq  ?control  Hover- 

Thrusters)  ) 


-> 

(decision-change  Maneuvering  Maneuvering_Status_Assessment 

naneuvering-assessnent  change-overall-maneuvering-status ) 
(assert  (Maneuvering_Status  severely_restricted) ) 

(assert  (propagate  change) ) ) 


; ; ; ;  Emergency  Evasive  Maneuvers  for  Obstacles  at  Close  Range 
;;;;  Based  upon  obstacle  alert  system  developed  by  C.  FLOYD 


(def rule  einergency_inaneuver_evaluation 

(or  (obstacle-flag-emergency  ?) 

(new-obstacle  on) ) 

-> 

(decision-change  Maneuvering  emergency_maneuver_jevaluation 
assessment 

assess_emergency_obstacle_avoidance_maneuvers  ) 
(bind  ?*avoidance_time*  ?*aiission__time*) 

(assert  (assess_avoidancejmaneuver) ) ) 

(defrule  Assess_Avoidance_Maneuver 
(declare  (salience  -500)) 

?assess  <-  (assess_avoidance_maneuver) 

7checlc  <-  (avoidance_time_checlc) 

•> 

(retract  ?check) 

(if  (>  ?*mission_time*  (+  ?*avoidance_time*  ?*recovery_time*)  )then 
(retract  ?assess) 

(assert  (maneuvering_ability  Ma jor_Restriction) ) 

(assert  (Maneuvering-Status-Assess) ) ) ) 


(defrule  emergency-evasive-maneuver-ascend 
(declare  (salience  1000) ) 

(or  (obstacle-flag-emergency  0001) 

(obstacle-f lag-emergency  0011) 

(^stacle-f lag-emergency  0101) 

(obstacle-flag-emergency  0111)) 

■> 

(decision-change  Maneuvering  emergency-evasive-maneuver-ascend 
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Low-8upervl8ory-l«v«l  •8C8nd__to_avoid_ob8tacle  ) 
(Call-Guldance-Comand  a8e«nd-?*8afa_dapth*  rudder  ) 
(aaaert  ((^atacle  Avoidance  reatrlctedl ) ) 


(defrule  emergency-evaalve-maneuver-leftaacend 
(declare  (aallence  1000) ) 

(ob8tacle-f lag-emergency  1101) 

-> 

(decialon-change  Maneuvering  emargency_eva8ive_maneuver-lefta8cend 
Low-aupervl8ory-level 
tum_left_and_a8cend_to_avold_ob8tcl) 
(Call-Guldance-Coomand  turn-left  rudder) 

(Call-Guidance-Command  ascend-10  planea) 

(asaert  (Obstacle  Avoidance  restricted) ) ) 


(defrule  emergency-evasive-maneuver-left 
(declare  (salience  1000)) 

(obstacle-flag-emergency  1100  ) 

-> 

(decision-change  Maneuvering  Mwrgency-evasive-maneuver-left 
Low-supervisory-level  tum_left_to_avold__obstacle) 
(Call-Guidance-Command  turn-left  rudder) 

(assert  (Obstacle  Avoidance  restricted) ) ) 


(defrule  emergency-evasive-maneuver-rightascend 
(declare  (salience  1000)) 

(obstacle-flag-emergency  1011  ) 

-> 

(decision-change  Maneuvering  emergency-evasive-maneuver- 

rightascend 
Low-supervisory-level 
tum_right__and_a8cend_to_avoid_ob8tacle) 
(Call-Guidance-CMsnand  turn-right  rudder) 
(Call-Guidance-Coamand  ascend  planes) 

(assert  (Obstacle  Avoidance  restricted) ) ) 


(defrule  emergency-evasive-aianeuver-right 
(declare  (salience  1000)) 

(obstacle-flag-esiergency  1010) 

-> 

(decision-change  Maneuvering  wnergency-evaslve-maneuver-rlght 
Low-level-supervisory  tum_right_to_avoid_ob8tacle) 
(Call-Guidance-Coamand  turn-right  rudder) 

(assert  ((Ostade  Avoidance  restricted) ) ) 
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(defrule  energency-evasive-maneuver-stopascend 
(declare  (salience  1000)) 

(or  (obstacle-flag-emergency  1110) 

(obstacle-flag-emergency  1111)) 

-> 

(declsion**c)iange  Maneuvering  emergency-evasive-’inaneuver-stopascend 
Low-level  -supervisory  Stop_f  orward_inoveinent_and_ascend) 
(Call-Guidance-Connand  Stop  Drive-motors) 

(Call-Guidance-Connand  ascend  planes) 

(assert  (Obstacle  Avoidance  restricted) ) ) 


'*04 

000i00000000000000000000000000§i0000*0000000000$000if0§§0000004 

0  0 

Special  configurations  which  can  easily  become 

0  0 

catastrophic  if  an  abnormal  condition  exists. 

0  0 

Diving,  ascending  and  surfacing  require 

0  0 

fast  reaction  to  counter  an  unstable  control 

0  0 

0  0 

system  or  an  obstacle  close-aboard 

(defrule  abnonnal_surface 
(configuration  ?config) 

(action  surface) 

(or  (Equlpinent_Failure  Control_System  Plane^Controls) 

(obstacle_clearance  ?clearancefi: (neq  ?clearance  normal))) 


-> 

(decision-change  Maneuvering  abnormal^surface 
Low-supervisory-level 
1 ncrea se_speed_t o_sur f ace ) 
(Call-Guidance-Command  Increase-Speed  Drive-motors) 
(assert  (maneuvering_ability  Ma jor_Restrictlon) ) 
(assert  (Assess-Manueuvering-Status) ) ) 


(defrule  abnormal_ascent 
(configuration  ?config) 

(action  surface) 

(or  (Equipiiient_  Failure  Control_Systeim  Plane_Controls) 

(obstacle_clearance  ?clearance&: (neq  ?clearance  normal))) 

-> 

(decision-change  Maneuvering  sbnormal_ascent  Low_supervisory_level 
increase_speed_of_ascent ) 

(Call-Guidance-Conmand  Increase-Speed  Drive-motors) 

(assert  (Bianeuvering_abllity  Ma  jor_Restriction) ) 

(assert  (Maneuvering-Status-Assess) ) ) 
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(defrule  abnonnal_dive 
(configuration  ?conflg) 

(action  dive) 

(or  (Equipment^Failure  Control_System  Plane^Controls) 

(obstacle_clearance  ?clearancefi : (neq  ?clearance  normal))) 

-> 

(decision-change  Maneuvering  abnonnal_dive  LoM_supervisory_level 
decrease_8peed_of__dive_ascend_to_8afe_depth) 
(Call-Guidance-Command  Decrease-Speed  Drive-motors) 
(Call-Guidance-C<»nand  ascend-?*safe_depth*  Planes) 

(assert  (maneuvering_abillty  Ma jor_Restrictlon) ) 

(assert  (Maneuvering-Status-Assess) ) ) 


; ; ;  Sensor_Limit  Obstacle  Detection 

0  0  f 

0  0  0 

; ; ;  These  Rules  interface  with  the  Obstacle  Avoidance 
;;;  DeclsionMaker .  Most  of  these  conditions  can  only  be 
; ; ;  simulated  until  the  Obstacle  Avoidance  DecisionMalcer 
; ; ;  is  co«q)leted 
0  0  0 

000000000000000000000000000000000000000000000000000000000000000000 


;  Detection  of  a  "new"  obstacle  ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 
;  The  obstacle  is  assigned  an  ID  reference  number  for  trac)cing 
;  As  the  OBSTACLE  class  message-handler  indicates  above, 

;  we  are  only  interested  in  obstacles  in  a  180-degree  arc 
;  about  the  bow 
;  the  )x>w. 


(defrule  Obstacle_Detection_Nonnal_Llmits 
?obstflag  <-  (obstacle_alert  on) 

?new_one  <-  (new_obstacle  on) 

•> 


(decision-change  Maneuvering  (^staclejdetection_Normal__Limit8 
Low_assessment  classify_normal_range_obstacle_as_new) 


(bind  ?*obstacle_ref*  (+ 
(malce-instance  (gensym*) 


?*obstacle_ref*  1)) 
of  OBSTACLE 
(lD_num 
(bearing 
(type 

(proximity 


(read  obstacles)) 
(read  obstacles) ) 
(read  obstacles)) 
(read  obstacles)) 


124 


(bmg_dri£t  (read  obstacles) ) 
(tiine_observed  (read  obstacles)) 
(con£idence_£actor  (read  obstacles) ) 
(collislon_danger  unlcnown) ) 
(do-£or-instance  ( (?obstacle  OBSTACLE) ) 

(eq  ? obstacle :ID_nuin  ?*obstacle_re£*) 

(send  ?obstacle  obstacle-change) ) 

(retract  ?new_one) ) 

; ; ;  Update  to  previously  detected  obstacle 


(de£rule  Obstacle_Update 
?obst£lag  <-  (obstacle_alert  on) 

?update  <-  (obstacle_update  on) 

-> 

(decision-change  Maneuvering  Obstacle_Update  Low_assessment 

update_obstacle_status : rangebearing, collision-danger) 
(bind  ?current_obstacle  (read  obstacles)) 

(do-£or-instance  ((?obstacle  OBSTACLE)) 

(eq  ?obstacle : ID_niun  ?current_obstacle) 

(progn  (send  ?obstacle  put-bearing  (read  obstacles)) 

(send  ?obstacle  put-type  (read  obstacles) ) 

(send  ?obstacle  put-proxindty  (read  obstacles)) 

(send  ?obstacle  put-brng_dri£t  (read  obstacles) ) 

(send  ?obstacle  put-tinie_observed  (read  obstacles)) 

(send  ?obstacle  put-con£idence_£actor  (read  obstacles) ) 
(send  ?obstacle  put-collision_danger  unlcnown) 

(send  ?obstacle  obstacle-change) ) ) 

(retract  ?update) ) 


;  Determines  whether  proportional  amount  o£  obstacles  are  to  the; 
;le£t  or  right  to  heuristically  determine  which  way  to  turn.  Z£  ; 
; actually  blocked  on  both  sides,  calls  £or  a  replan  of  the  route.; 


(de£rule  Collective_Obstacle_Assessment 
(collective_obstacle_assessment) 

-> 

(decision-change  Maneuvering  Collective_Obstacle_Assessroent 
Low^assessment 

assess_whether_presents_a_collision_danger_and_turn) 

(bind  ?obstacles_le£t  0) 

(bind  ?obstacles_right  0) 

(do-£or-all-instances  ((?obstacle  OBSTACLE)) 

(eq  ?obstacle:collision_danger  YES) 

(i£  (and  (>*  ?obstacle: bearing  270.)  (<>  ?obstacle: bearing  359.)) 

then 
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(bind  ?obstacles_left  (■•■  ?obstacles_left  1)) 
else 

(bind  ?obstacles_right  (-1-  ?obstacles_right  1)))) 

(if  (>  ?obstacles_le£t  ?obstacles_right)  then 
(bind  ?tum  turn_right)) 

(if  (>  ?obstacles_right  ?obstacles_left)  then 
(bind  ?turn  turn_left) ) 

(if  (and  'eq  ?obstacle8_right  ?obstacles_left) 

(neq  ?obstacle8_right  0) )  then 
(bind  ?turn  rever8e_cour8e) 

(aeeert  (0b8tacle_Avoidance  reetricted) ) 
(Replan-Route  ?tum  ?*<3oalx*  ?*Goaly*  ?*c;oalz*)> 

(if  (oz  (>  ?ob8tacle8_left  0)  (>  ?ob8tacle8_right  0) )  then 
(aaaert  (Call-Guidance-Conmand  ?turn  rudder) ) ) 

(aaaert  (Maneuvering-Statua-Aaaeaa) ) ) 
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Programmer 

System 

Program 

Functional  Area 
Latest  Revision 


W  P  Wilkinson 
CLIPS  5.0 

AUV  Mission  Executor  "SKIPPER" 

Sub_System  Monitoring  (Vehicle  Internal  World) 
30  August  91 


Description 

This  is  the  high-level  abstraction  of  the  system  monitoring 
functions  of  the  AUV.  This  module  is  designed  to  be  an  overall 
subsytem  "health"  monitor  and  performs  both  high-level  and  low 
level  polling  of  subsystems  state.  Some  of  the  AUV  systems 
(all  of  which  are  modeled  as  objects)  include  the 

power_sources,  navigation  instruments,  sonars,  environmental_sensors 
and  control_sys terns  such  as  rudders,  planes,  thrusters.  A  continuous 
loop  polls  all  systems,  and  the  message-handlers  associated  with  each 
class  attempt  to  determine  if  a  reading  is  out  of  range.  These  in 
turn  produce  facts  which  cause  equi^nent  rules  to  fire. 

Failure  conditions  cause  the  Equipment  assessor  rule  to  determine 
if  an  equipment  going  critical  or  an  ecjuipment  failure  will  cause 
a  restriction.  If  the  functional  area  of  Equi{8nent_Status  has  a 
a  degradation,  this  is  passed  to  the  Overall  Mission  Assessor  in 
in  main  file  skipper. dp  . 


; ; ; ; ; ;  Global  Variables  Pertaining  to  Equipment  Monitoring; ; 


(def global  ?*sysmonitor_salience"  -  100 

?*QtyEquipnent_f  ailed*  0 

?*NrNavInstruroentsfailed*  ■>  0 

?*NrSonar failed*  -  0 

?*NrEnvironSensorsf ailed*  -  0) 


AUV  Subsystem  Monitor  Objects 


f 


4 


(defclass  SYSTEMJMONITOR  (is-a  USER) 

(slot  type_of_reading) 

(slot  reading) 

(slot  degradation_tlme) 

(slot  status  (default  NORMAL) ) 

(slot  Redundant_Equipment  (initialize-only) ) 
(slot  redllne_hlgh  (initialize-only) ) 

(slot  guardline_high  (initialize-only) ) 

(slot  guardline^low  (initialize-only) ) 

(slot  redllne_low  (initialize-only) )  ) 
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Power  sources  which  support  the  various  equlpaaents  ;;;; 


(defclass  PONER_SOURCE  (Is-a  SySTEM_MOMITOR) 

(slot  type_of_reading  (default  power_in_watts) ) 
(slot  Redundant_Equipaent  (default  NtME)) 

(slot  Altemate_Source  (initiallse-only) ) 

(slot  redline_high  (default  0.0)) 

(slot  guardllne_hlgh  (default  0.0)) 

(slot  Equlp(nent_Supported) 

(message-handler  get-reading) ) 


(defmessage-handler  PQWER_SOURCE  get-reading  after  () 

(if  (and  (<  ?self : reading  ?self :guardllne_low) 

(>  ?self treading  ?aelf :redline_low) )  then 
(assetrt  (Equipment_Crltical  ?self : Equipment^Supported) ) 
(assert  (Power  Source  failure  ) ) ) ) 


; ; ; ; ; ; ;  Sonar  class  and  objects  ;;;;;; ; ; ; ; ; 

(defclass  SONAR  (is-a  SYSTEM_M0N1T0R) 

(slot  type-of-reading  (default  f requency_in_hz) ) 
(slot  redline_high  (default  50.0)) 

(slot  guardline_high  (default  40.0)) 

(slot  guardllne_low  (default  5.0)) 

(slot  redllne_low  (default  1.0)) 

(slot  statuschange^time  (default  0.0)) 

(slot  recove ry_time  (default  20.0)) 

(message-handler  get-reading) ) 


Chec)c  Sonar  readings  for  out-of-limit  readings 


(defmessage-handler  SONAR  get-reading  after  () 

(bind  Tsonar  (instance-name-to-symbol  (instance-name  ?self ) ) ) 
(if  (or  (and  (>  ?self : reading  ?self :guardline_high) 

(<  ?self treading  ?self tredline_high) ) 

(and  (<  ?self t reading  ?self tguardline_low) 

(>  ?self t reading  ?self tredlinew) ) )  then 
(assert  (Equipinent_Critical  Sonar  ?sonar) ) 

(send  ?self  put-statuschange_time  ?*mission_time*) 

(send  ?self  put-status  CRITICAL) 
else 

(if  (or  (>  ?self t reading  ?self tredline_high) 

(<  ?self t reading  ?self t redline_low) )  then 
(assert  (Equipment_Failure  Sonar  ?8onar) ) 

(bind  ?*NrSonar failed*  ?*NrSonarfalled*  1)) 

(send  ?self  put-status  INOPERATIVE) ) ) ) 


(defclass  HAVZGATZON_INSTRUMEHT  (Is-a  SYSTEMJMONZTOR) 
(slot  type_of_reading  (default  power_in_watts) ) 
(slot  tlme_critical  (default  0.0)) 
(message-handler  get -reading  ) ) 


; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;  Zf  a  Navigation  instrument  is  out  of  limits 
; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;  then  tabulate  the  nuxdser  failed  and  declare  it 
;;;;;; ; ; ; ; ; ; ; ; ; ; ;  failed 

(defmessage-handler  NAVZ(3ATZ0N_ZNSTR'UHENT  get-reading  after  () 
(bind  ?instrument  (instance-name-to-symbol  (instance-name  ?self ) ) ) 
(if  (or  (>  ?self: reading  ?self :guardline_hlgh) 

(<  ?self treading  ?self :guardline_low) )  then 
(assert  (Equii»nent_Failure  Nav_Znstrument  ?instrument) ) 

(bind  ?*NrNavZnstrumentsfailed*  (-•-  ?*NrNavZnstrumentsfailed*  1) ) 
(send  ?self  put-status  INOPERATIVE) ) ) 

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;  Control  Systems  ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 
;;;;;;;;;;;;  Zf  these  fail,  this  will  eventually  cause  a  mission  ; 
;;;;;;;;;;;;  abort,  unless  the  control  is  a  Hover-Thruster,  which; 
;;;;;;;;;;;;  at  this  stage  of  AUV  development,  is  not  mission-  ; 

; ; ; ; ; ; ; ; ; ; ; ;  critical  ; 

(defclass  CONTROL_SYSTEM  (is-a  SYSTEM_MONZTOR) 

(slot  typ>e_of_readlng  (default  potential_in_volts) ) 

(slot  statuschange_tiroe  (default  0.0)) 

(slot  recovery_time  (default  10.0)) 

(slot  control -type) 

(slot  response  (default  normal) ) 

(message-handler  get -reading) 

(message-handler  get-response) ) 


(defmessage-handler  C<Hn'ROL_SYSTEM  get-reading  after  () 

(bind  ?control  (instance-name-to-symbol  (instance-name  7self ) ) ) 
(if  (or  (and  (>  ?self : reading  ?self :guardline_high) 

(<  ?self: reading  ?self :redline_high) ) 

(and  (<  ?self treading  ?self :guardline_low) 

(>  ?self treading  ?self tredline_low) ) )  then 
(assert  (Equipment_Critical  Control_System  ?control) ) 

(send  ?self  put-status  CRITICAL) 

(send  ?self  put-statuschange_time  ?*mission_time*) 
else 

(if  (or  (>  ?self treading  ?self t redline_high) 
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(<  ?sel£ : reading  ?8el£ : redllne_low) )  then 
(assert  (Equlpnent^Fallure  Cent rol_Sy8 tern  ?control) ) 
(send  ?sel£  put-status  INOPERATIVE)))) 


This  is  an  added  chec)c  £or  control  systeois  instead  o£  the 
just  the  electrical  status.  If  a  control  system  does  not 
respond  or  is  in  the  wrong  position  ,  this  is  an  indication 
o£  impending  £ailure  and  is  justi£ication  £or  a  status  of 


CRITICAI. 


(deimsssage-handler  C<R<TROL_SYSTEM  get-response  a£ter  () 
(i£  (neq  ?sel£: response  normal)  then 

(assert  (EquipnentjCritical  Control_Sy8tem  ?8el£) ) 
(send  ?8el£  put-status  CRITICAL) ) 

(send  ?sel£  put-statuschange_time  ?*inl8sion_tiaie*) ) 


% 


1 


Environmental  Sensors  are  evaluated  £or  both 
electrical  status  and  the  environmental  reading  they 
indicate  even  when  operating  properly. 


(de£class  ENVIRON_SENSORS  (is-a  SYSTEM_MONITOR) 
(slot  type  (initialize-only) ) 

(slot  environment al_reading  ) 

(slot  environment__upperlimit  (initialize-only) ) 
(slot  statuschange^^time  (de£ault  0.0)) 

(slot  Redundant_£quipment  (de£ault  NCms)) 
(message-handler  get-reading) ) 


$9f90$$i$90tt9f0f$9909t990909999f099$0ff99f9t$»f99$»§9f99»99f9 

; ; ;  This  checks  the  environmental  sensors  £or  proper  ; ; ; 

; ; ;  operation  ; ; ; 

(de£message-handler  ENVlRON_SENSORS  get-reading  a£ter  () 

(bind  ?sensor  (instance-name-to-symbol  (instance-name  ?8el£) ) ) 

(i£  (or  (>  ?sel£ : reading  ?sel£:redline_high) 

(<  ?sel£ : reading  ?sel£:redline_low) )  then 
(assert  (  Equipment_Failure  Environ_Sensor  ?8ensor  ) )  » 

(bind  ?*NrEnvironSensor8£ailed*  (4-  ?*NrEnvironSensor8£ailed*  1) ) 

(send  ?sel£  put-status  INOPERATIVE))) 
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'  9  9 

"7" 

i  0 

Environment  Limits  Readings 

0 

0  0 

This  chec)cs  the  environmental  sensors  for 

0 

0  0 

environmental  conditions  which  are  out  of  limits. 

0 

0  0 

The  rules  which  operate  on  these  limits  are  part 

0 

0  0 

of  the  environmental  world  and  are  found  in  module 

0 

0  0 

environment. dp.  This  message-handler  operates 

0 

0  0 

on  that  world  and  is  only  included  here  for 

0 

0  0 

convenience  and  polling. 

0 

0 

(defmessage-handler  ENVIRON_SENSORS  9et-environinental_reading 

after  () 

(bind  ?aen8or  <lnatance-naaie-to>ayiiibol  (instance-name  ?self ) ) ) 
(if  (>  ?self: environment al_reading  ?self :environment_upperlimit) 
then 

(assert  (Adverse_condition  ?self:type  ?sensor) ) 

(send  ?self  put -status  INOPERATIVE) ) ) 


; ;  Mission  equipment  is  represented  among  the  equipment 
;;  monitoring  objects  although  it  has  little  bearing  on 
;;  present  AUV  missions  in  the  NFS  pool. 

(defclass  MISSION_EQUIPMENT  (is-a  SYSTEMJMONITOR) 

(slot  type_of_reading  (default  potential_in_volts) ) 
(slot  statuschange__tlme  (default  0.0)) 

(slot  type  (initialize-only) ) 

(message-handler  get-reading) ) 


(defmessage-handler  MZSSION_EQUZPMENT  get-reading  after  () 

(bind  ?instrument  (instance-name-to-syndbol  (instance-name  ?self ) ) ) 
(if  (or  (>  ?self: reading  ?self :guardline_high) 

(<  ?self: reading  ?self :guardline_low) )  then 
(assert  (Equipment_Failure  Mission_Znstrument  ?instrument) ) 
(send  7self  put-status  INOPERATIVE))) 
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(d«fin8tanc«8  Sy88»nltor-‘B8iik 

(Auxl_B8t  of  POllBR_SoaRCB  (toading  40.0) 

(Alt«rnat*_8ourc«  HOME) 
(gu8rdliii8_low  10.0) 
(rodliMi_low  S.O) 

(Equip— nt_8npporfd  NONE) ) 

<FNDSonar_Bat  of  PONER_SOURCE  (raading  40.0) 

(Altarnata_Sourca  Auxl_Bat) 
(guardllna_low  10.0) 
(radllna_low  5.0) 

(Equip— nt_Supportad  FND-aonar)) 

(PORTSonar_Bat  of  PONER_SC»mCE  (reading  40.0) 

(Altemata^Source  AuxljBat) 
(guardline_low  10.0) 
(redline_low  5.0) 

(Equipaumt^Siqipoxted  PORT>8onar) ) 

(STBDSonar_Bat  of  PONER^SOORCE  (reading  40.0) 

(Altemate_Source  Aoxl_Bat) 
(guardline_low  10.0) 
(redline_loe  5.0) 

(Equip— nt_Si;VP<»^*d  STBD-aonar)) 

(DEPTHSonar^Bat  of  PONER^SOURCE  (reading  15.0) 

(Altemate^Source  AuxljBat) 
(guardline_low  10.0) 
(redline_low  5.0) 

(Equip— nt_8upported  DEPTR-aonar) ) 

(FND-aonar  of  SONAR  (reading  35.0) 

(Radundant_Equip— nt  NONE)) 

(P<mT-8onar  of  SONAR  (reading  35.0) 

(Redundant_BquipaMnt  NONE)) 

(STBD-aonar  of  SONAR  (reading  35.0) 

(ReAindant_Bquipa»nt  NONE)) 

(DEPTN-aonar  of  SONAR  (reading  ~35.0) 

(Redundant_EqulpaMnt  NONE) ) 
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(Aux2_Bat  of  PONER_SOURCE  (roading  25.0) 

(Alternate_Source  IKHIE) 
(9uardlina_low  7.0) 
(r«dllne_low  1.0) 
(Bqulpnant_Support«d  None  M(NIE) ) 

(DeadReckon_Bat  of  PONER__SOURCE  (reading  25.0) 

(Altemate_8ource  Aux2_tat) 
(guardline_low  7.0) 
(redllne_low  1.0) 

(  Bquii»ent_Sui>ported  Navigatlon_Zn8trumnt 

DeadReclconAnalyxer  ) ) 

(G!yro_Bat  of  PONER_SOURCE  (reading  25.0) 

(Altemate_Source  Aux2_Bat) 
(guardline_loir  7.0) 
(redline__low  1.0) 

(EquipfBent_Sui^rted  Navigation_Xnstrument  (Syro) ) 

(DeadReckonAnalyzer  of  NAVXGATI(»l_IMSTRt]MENT  (reading  5.0) 

(RedundantJBquipment  Gyro  ) 
(redline_high  10.0) 
(guardline_high  8.0) 
(guardllne_low  4.0) 
(redline^low  2.0)) 

(Gyro  of  NAVlGATION_XNSTRUMENT  (reading  4.0) 

(Redundant_Equipawnt 
DeadReckonAnalyzer) 
(redline_high  6.0) 
(guardline_hig))  6.0) 
(guardllne_low  2.0) 
(redline.l^  1.5)) 

(Aux3_Bat  of  PONER_SOURCE  (reading  50.0) 

(Altemate_Source  NONE) 
(guardline_low  10.0) 
(redline_low  1.0) 
(Equipaient_Supported  N(WE) ) 


(Hover_Bat  of  PONER_SOURCE  (reading  50.0) 

(Altemate_Source  Aux3_Bat) 
(guardline_low  10.0) 
(redline_low  1.0) 

(Equipaient_Supported  Control_Syateai  Hover-Thrusters) ) 

(Motorl_Bat  of  PONER_SOURCE  (reading  50.0) 

(Altemate_Source  Aux3_Bat) 
(guardline_low  10.0) 
(redline  low  1.0) 
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(BquipMnt_Sai^rt«d  Control^SystanDrive-Motorl) ) 

(Motor2_Bat  of  PONER.SOURCE  (roading  50.0) 

(Alt«mate_Source  Aux3_Bat) 
(guaxdline__low  10.0) 
(radlina_lo«r  1.0) 

(Equlpeient^Su^ortad  Control_Systam  Drlve-Motor2) ) 

(Planes_Bat  of  PONER_SOURCE  (raading  50.0) 

(Altarnate_Source  Aux3_Bat) 
(guardlliia_low  10.0) 
(radlina_low  1.0) 

(EqulpeMnt_Supportad  Control^Syataa  Plana-Controls) ) 

(Ruddar_Bat  of  PONER.SOURCE  (raading  50.0) 

(Altamata_Sourca  Aux3_Bat) 
(guardlina_loH  10.0) 

( radlina_low  1.0) 

(Equipoient^Supportad  Rudder) ) 

(Hover-Thrusters  of  CONTROL_SYSTBM  (reading  7.0) 

(control-type  auxiliary) 
(redline_high  10.0) 
(guardline_high  8.0) 
(guardline_low  4.0) 
(redline_low  2.0)) 

(Drive-Motorl  of  CONTROL^SYSTEM  ~ 

(reading  7.0) 

(control-type  propulsion) 
(redline_high  12.0) 
(guardline_high  8.0) 
(guardllne_low  4.0) 
(redline_low  2.0)) 

(Drive-Motor2  of  CONTROL_SYSTEM  (reading  7.0) 

(control-type  propulsion) 
(redline_high  12.0) 
(guardline_high  8.0) 
(guardline_low  4.0) 
(redline^low  2.0)) 

(Plane-Controls  of  CX)NTROI._SYSTEM  (reading  5.0) 

(control-type  depth) 
(redline_high  8.0) 
(guardline_U^  6.0) 
(guardllne_low  2.0) 
(redllne_loif  1.0)) 

(Rudder  of  C(xrrROL_STSTEM  (reading  5.0) 

(control-type  aziauth) 
(redlinejhigh  8.0) 
(g\iardline_high  6.0) 
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(guardllne_low  2.0) 
(redlintt_low  1.0)) 

(Aux4_Bat  of  POllER_SOURCE  (reading  20.0) 

(Altemata_Source  NOME) 
(guar<lline_lo«r  10.0) 
(redllne_lo«  1.0) 
(Equipnent_Supported  NONE) ) 

(SeaTenp_Bat  of  POIfER_SOURCE  (reading  20.0) 

(Altemate_Source  Aux4_Bat) 
(guardline_low  5.0) 
(redline_low  1.0) 

(Equiixiient_Supported  Bnviron_Sen8or  SeaTenpSenaor) ) 

(SeaState_Bat  of  POl(ER_SOURCE  (reading  20.0) 

(Altemate__Source  Aux4_Bat) 
(guardline_low  5.0) 
(redline_low  1.0) 

(Equipinent_Supported  Environ_Sensor  SeaState^ro) ) 


(SeaTempSensor  of  ENVIRON_SBNSORS  (reading  3.0) 

(environaiental_reading  55.0  ) 
(environaent_un>erliiiiit  90.0  ) 
(type  potential  ) 

( redlinejhigh  5.0) 
(guardline_high  4.0) 
(guardline_low  1.0) 
(redline_low  0.5)) 

(SeaStateGyro  of  ENVIRON_SENSORS  (reading  5.0) 

(enTironaental_reading  1.0  ) 
(environBient_upperliniit  2.0  ) 
(type  potential_in_volts) 

( redline_high  8.0) 
(guardline_high  6.0) 
(guardline_low  2.0) 

( redline_low  1.0)) 

(PressureTransducer  of  ENVIRON_SENSORS 

(reading  50.0) 

(environiiiental_reading  50.0  ) 
(environiiient_upperliaiit  75.0  ) 
(type  potential_in_volts) 

( redline_high  60.0) 
(guardline_high  55.0) 
(guardline_low  45.0) 

( redline_low  35.0)) 

(Hydrography_Instrl  of  MISSION_EQUIPMENT 

(reading  3.0) 
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<type  Surveying) 
(xedllne_hl9h  5.0) 
(guardline_hlgh  4.0) 
(9uardllne_low  1.0) 
(redllne  low  0.5))) 


This  continuously  polls  the  equipment  monitors  to 
detennine  if  the  equipment  power  readings  are  correct, 
indicating  that  the  equipment  is  functioning. 


(defrule  inonitor_health_continuously 
(declare  (salience  -500)) 

?iaonitor  <-  (system_monitors  running) 

-> 

(do-£or-all-instances  ((?sonar  SONAR)) 

(neq  ?sonar: status  INOPERATIVE) 

(send  ?sonar  get-reading) ) 

(do-£or-alI-instances  ((?power  PONER__SOURCE) ) 

(neq  ?power: status  INOPERATIVE) 

(send  ?power  get-reading) ) 

(do-for-all-instances  ( (?lnstruinent  NAVIGATION_IMSTRUMENT) ) 

(neq  ?instruinent:status'~INOPERATIVE) 

(send  ?instr\ainent  get-reading) ) 

(do-£or-all-instances  ( (?control  CONTROI<_SYSTEM) ) 

(neq  Tcontrol: status  INOPERATIVE) 

(send  ?control  get-reading) ) 

(do-£or-all-instances  ((?sensor  ENVIRON_SENSORS) ) 

(neq  ?sensor: status  INOPERATIVE) 

(progn  (send  ? sensor  get -reading) 

(send  ?sensor  get-environiaental_reading) ) ) 
(do-£or-all-instances  ( (?miss_instrument  MISSION_EQUIPMENT) ) 

(neq  ?miss_instrument: status  INOPERATIVE) 
(send  ?iaiss_instr\unent  get-reading) ) 

(retract  Tmonitor) 

(assert (check  critical-equipment))) 
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(defrule  chec)c_critical_equli»ient 
(declare  (salience  -500)) 

?checlc  <-  (chec]c  critical -equiianent) 


(do-for-all-instances  ( (?sonar  SONAR) ) 

(eq  ?sonar: status  CRITICAL) 

(progn  (if  (and  (>  ?sonar treading  ?sonar:guardline_low) 

(<  ?sonar treading  ?sonartguardline_high) )  then 
(assert  (EquipfDent_Recovery  Sonar  ?sonar) ) 

(put  ?sonart status  NORMAL) 
else 

(if  (>  ?*mission_time*  (+  ?sonartstatuschange_tiine 

?sonartrecovery_tiine) )  then 
(put  ?sonart status  INOPERATIVE) 

(assert  (Equipinent_Failure  Sonar  ?sonar) ) 

(send  ?sonar  put-status  INOPERATIVE) ) ) ) ) 

(do-for-all-instances  ((?control  CONTROL_SYSTEM) ) 

(eq  ?controlt status  CRITICAL) 

(progn  (if  (and  (>  ?control t reading  ?controltguardline_low) 

(<  ?control treading  ?controltguardline_high) )  then 
(assert  (Equipment_Recovery  Control_Systein  ?control)) 

(put  ?controlt status  NORMAL) 
else 

(if  (>  ?*inission_tiine*  (+  ?control t  statuschange_tiine 
?control  t  recovery_tiine) )  then 
(put  ?controlt status  INOPERATIVE) 

(assert  (EquiiMnent_Failure  Control_System  ?control) ) 
(send  ?control  put-status  INOPERATIVE))))) 

(retract  ?chec)c) ) 


Assesses  the  ing>act  of  loss  or  crippling  of 
vital  equipment  . 


(defrule  Equipiiient_Status_Assessinent 

(declare  (salience  ?*sysmonitor_salience*) ) 

(or  (Equipinent_Critical  ?class  ?Equipiiient) 
(Equipment_Failure  ?class  ?Equipment) ) 
(Equipment_Mission_Essential  ?essential) 

?assessflag<-  (Equipment-Status-Assess) 

?statusflag  <-  (Equipraent_Status  ?status) 

-> 

(bind  ?*sysmonitor_salience*  (+  ?*sysmonitor_salience*  1)) 
(decision-change  System_Nonitor  Equipaient_Status_Assessinent 
Assessment  Assessing^Status  ) 
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(bind  ?*QtyEqulpm»nt_£all«d*  C-f  ?*QtyBqiiipnMit_£all«d*  1)) 
(If  (or  (>  ?*QtyEquipaMnt_£all«d*  2) 

(€Ki  ?«s8entlal  yes))  then 
(retract  ?statusfla9) 

(assert  (Equipment_Statu8  ma jor_£ailure) ) 

(assert  (propagate  change) ) 

else 

(retract  ?statu8flag) 

(assert  (Equipaient_Status  equipraent__critlcal) ) 

(assert  (propagate  change  ) ) ) 

(retract  ?as8es8£lag) ) 


Establishes  whether  or  not  equlpmnt  has  recovered.  ;;; 


(defrule  Equipiiient_Recovery 

(declare  (salience  ?*sysiiionltor_8allence*) ) 

(Equlpinent_Recovery  ?cla8S  ?equlpinent) 

-> 

(decision-change  System_Monltor  Equlpaent_Recovery  Assessment 
resuine^nomal_equip_operatlons ) 

(bind  ?*QtyEqulpinent_f ailed*  (-  ?*QtyEquipment_£ailed*  1)) 

(If  (eg  ?*OtyEqulpinent_falled*  0)  then 
(assert  (Equlpiiient_$tatu8  normal)) 

(assert  (propagate  change)))) 


; ; ;  attea^ts  to  shift  to  alternate  power  source  if  one  avail 
;;;  places  failed  power  source  in  the  INOPERATIVE  mode 

(defrule  Power_Source_Crltlcal 
(Power_Source  failure) 

(Equlpinent_crltlcal  ?equlp_clas8  ?Equlpment) 

(Altemate_Power_Source  ?80urce) 

-> 

(decision-change  SystemJKonltor  Power_Source_Critlcal  Low 
shift-power-source  ) 

(Call -Guidance-Command  shlft-powersource-to  ?source  ) 

(send  (symbol-to-lnstance-naaw  ?80urce) 

put-Equlpnent_Su^orted  ?EqulpiBent) 

(do-for-lnstance  ((7Battery  PONER_SOURCE) ) 

(eq  ?Battery:EqulpBwnt_Supported  ?Equlpiiient) 
(send  ( symbol -to-lnstance-name  ?Battery)  put-status  INOPERATIVE) ) ) 
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Sonar  Failure 

Determines  if  sonar  failure  is  critical.  If  the 
depth  sonar  falls,  the  mission  will  be  aborted. 
In  any  case,  the  efiact  must  be  reported  to  the 
Intermediate  level  assessment  rule. 


(defrule  Sonar_Failure 

(Equlpinent_Failure  Sonar  ?some_sonar) 

-> 

(decision-change  System^Monitor  Sonar_Fallure  Low 
Pass_info_to_Equip_Assessor) 

(if  (eq  ?some_sonar  DEPTH-sonar)  then 

(assert  (Equipment_Misslon_Essential  yes) ) 

(assert  (Equipment-Status-Assess) ) 

else 

(assert  (Equipment_Mission_Essential  no) ) 
(assert  (Equipment-Status-Assess) ) ) ) 


(defrule  Sonar_Critical 

(Equipment_Critical  Sonar  ?some_sonar) 

->  ~ 

(decision-change  System__Monitor  Sonar_Critical  low 
Pass_info_to_Equip_Assessor) 

(if  (eq  ?some_8onar  DEPTH-sonar)  then 

(assert  (Equipment_Mission_Essential  yes)) 

(assert  (Equipment-Status-Assess) ) 

else 

(assert  (Equipment_Mission_Essential  no) ) 
(assert  (Equipment-Status-Assess) ) ) ) 


; ; ;  Atteiig>ts  to  shift  to  back  up  nav  instrument  when  one  goes 
; ; ;  critical 

(defrule  Navigatlon_Instruinent_Failure 

(Equipment_critical  Navlgation_Instrument  ?instrument) 

-> 

(decision-change  SystemJHonitor  Navigation_Instrument_Failure  Low 

Shi f t_to_Redundant_Equipment ) 

(do-for-instance  ( (?other-instruinent  NAVIGATION_INSTRUMENT) ) 

(and  (eq  ?other-instruroent:Redundant_Equipinent 

?instruinent) 

(eq  ?other-instrximent: status  normal)) 
(Call-Guidance-Conmand  Shift-NavInstrument-to  ?other-instrument) ) 
(assert  (Equipnient_Mission_Essential  no) ) 
p  (assert  (Equipment-Status-Assess) ) ) 
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; ; ;  Control  Syotom  Failure  ; ; ; 

; ; ;  Assesses  any  control  system  failure  except  for  ; ; ; 

; ; ;  Hover-Thrusters  as  a  failure  of  mission-essential  ; ; ; 

; ; ;  (i . e . ,  vital)  equipment .  ; ; ; 

fifiittffitSiittiiiitlttStiitiSSiSiitttiStSttfSiflitiitiiit 

(defrule  Control_System_Critical 
(Equipment_Critical  Control_System  ?control) 

•»> 

(decision-change  SystemJHonitor  Control_System_Crltlcal  Low 
Pass_lnfo__to_Equip_Status_Assessor) 

(if  (neq  ?control  Hover-Thrusters)  then 
(assert  (Equi{»nent_Mlssion_Essential  yes) ) 

(assert  (Equipment -Status -Assess) ) ) ) 


(defrule  Control_System_Failure 

(Equipment_Failure  Control_System  ?control) 

> 

(decision-change  System_Monitor  Control_System_Failure  I>oit 
Pass_info_to_Equip_Assessor) 

(if  (eq  ?control  Hover-Thrusters)  then 

(assert  (Equipment_Mission_Essential  no) ) 
else 

(assert  (Equipment_Mission_Essential  yes) ) 

(assert  (Equipment-Status-Assess) ) ) ) 


000000000000000000000000000000000000000000000000000000 

0 

Environmental  Sensor  Failure 

0 

0 

These  have  the  least  effect  on  the  Equipment 

0 

functional  area.  The  pressure  transducer  is  the 

0 

0 

0 

only  environmental  sensor  considered  vital 

0 

0 

(defrule  Environroental_Sensor_Failure 
(Equipment_Failure  Environinental_Sensor  ?sensor) 

-> 

(decision-change  System_Monitor  Environment al_Sensor_Fallure 
Low  Pass_info_to_Equip_Status_Assessor) 

(if  (neq  ?sensor  PressureTransducer)  then 
(assert  (Equipment_Mlssion_Essential  no) ) 
else 

(assert  (Equipment_Misslon_Essential  yes) ) 

(assert  (Equipment-Status-Assess) ) ) ) 
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Prograimer  W  P  Wilkinson 

System  :  CLIPS  5.0 

Program  AUV  Mission  Executor  "SKIPPER" 

Functional  Area  :  Environment 

Latest  Revision  04  Sep  91 


Description 

This  is  the  abstraction  of  the  Environmental  world. 
Environmental  out  of  limits  readings  cause  the  environment 
to  degrade,  but  mostly  are  isolated  phenomena.  If  a 
collective  degradation  occurs,  this  signifies  a  negative 
trend  in  the  environment  and  reason  for  AUV  to  abort  the 
mission. 


; ; ; ;  Global  Variables  Pertaining  to  Environment 


(defglobal  ?*environinent_salience*  -  100 
?*QtyEnvironProblems*  ■*  0 

?*sea  state  thresh*  -  3) 


Environmental  Assessor 


This  assumes  that  a  single  environment  problem  is  not  critical 
in  itself.  Rather,  an  aggregate  of  out-of-range  sensor  readings 
indicate  a  large  environmental  phenoaiena  such  as  a  storm.  In 
such  a  situation,  the  environmental  situation  would  be 
severely  degraded,  causing  AUV  to  abort  the  mission. 


(defrule  Environment_Assessor 

(declare  (salience  ?*envlronment_salience*) ) 

?cond  <-  (Adverse_condition  ?type  ?equipment) 

?current  <-  (Environmental_Status  ?status) 

•  -> 

(retract  ?cond) 

,  (decision-change  Environmentaljworld  Environaient_Assessor 

Assessawnt  deteniiine_if_envlronment_status_is_hazard) 
(bind  ?*(}tyEnvironProblems*  (  +  ?*(}tyEnvironProbl«iis*  1)) 

(if  (>«  ?*QtyEnvironProblems*  3)  then 
(retract  ?current) 

(assert  (Environmental_Status  ma jor_devlation) ) 

(assert  (propagate  change) ) ) ) 
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; ; ; ; ; ; ; ; ; ; ; ; ; : :  i : : : : : : :  t :  i  i !  i  i  s  s ;  i  i ; ; ; ; ; ; ; ; ; ; ; ; ; ; 
Separate  rule  (implicit  "or"  with  the  rule  above) 
to  Indicate  the  effect  of  a  sensor  loss 


(defrule  Environinent_Assessor_Equlpeient 

?equlp  <-  (Equlpoient_Failure  Environ_Sensor  ?sensor) 
?environ_status  <-  (Envlronnental_Status  ?status) 

-> 

(decision-change  Envlroniiiental_world  Environinent_Assessor 

Assessment  determine_if_environmentjequipfailure_is_hazard) 
(bind  ?*(2tyEnvironProblems*  (  +  ?*QtyEnvironProbleffls*  1)) 

(if  (>-  ?*QtyEnvironProblems*  3)  then 
(retract  ?envlron_status) 

(assert  (Environmental_Status  ma jor_deviatlon) ) 

(assert  (propagate  change) ) ) 

(retract  ?equlp) ) 


Environmental  World  Rules 

This  handles  environmental  sensor  readings  which  are 
out  of  limits,  liow  level  actions  to  guidance  are 
immediately  generated  while  the  command  to  collectively 
assess  the  environment  is  made. 

r ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;;;;;; ; ; ; ; ; ; ; ; 


(defrule  attitude_sensor 

(Adverse_condition  attitude  Tequipment) 

-> 

(decision-change  Environmental_world  attltude_sensor 
Low_level  dive_to_avold_ocean_turbulenee) 
(Call-Guidance-Comroand  dive-24  planes) 

(assert  (Assess  Environment) ) ) 


(defrule  pressure_sensor 

(Adverse_condltion  pressure  Tequipment) 

-> 

(decision-change  Envlronmental_world  pressure__sensor  Low-level 
ascend_to_avoid_pressure_limit s ) 

(Call-Guldance-Cosmand  ascend-10  planes) 

(assert  (Assess  Environamnt) ) ) 
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(defrule  tttiaperature__8ensor 

(Adver8e_condition  temperature  ?equipinent) 

->  ~ 

(decialon-change  Environiiiental_world  temperature_8en8or  Low_level 
detemlne_lf_temp__change_ln<llcate8_navlgatlon_error) 
<Call-Guidance-CoaBiand  Verlfy-Locatlon  navigation) ) 
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APPENDK  B.  TESTING  SCENARIOS 


1.  SCENARIO  1 

CL1PS>  (watdi  statistics) 

CLIPS>  (batch  uploadbat) 

CL1PS>  (close) 

FALSE 
CL]PS>  (clear) 

CLIPS>  (loid  skqiP^'Clp) 

Definiiig  defglobal:  *start_tiine* 

Defimng  defglobal:  *iiiissioii_tiine* 

Defining  defglobal:  *niission_degradation_tinie* 

Defining  defglobal:  *recoveiy_tinie* 

Defining  defglobal:  *11me_Interval* 

Defining  defglobal:  *eniefgency_salien(%* 

Defining  defglobal:  *mission_critical_power* 

Defining  defglobai:  *Fiinctional_aiea Julnre* 

Defining  defglobal:  *Functional_afea_ciitical* 

Defining  defglobal:  *ciitrent.evait* 

Defining  defglobal:  *Goalx* 

Defining  defglobal:  *Goaly* 

Defining  defglobal:  *Ooalz* 

Defining  deffunctkm:  diow-deino-desci^on 
Defining  deffunction:  copy<<dd-instance 
Defining  defdass  blods  DEQSION 
Defining  deffiinction:  decision-change 
Defining  defdass  blodc  EVENT.SCHEDULE 

Defining  defmessage-handler  execute-event  immary  in  class  EVENT.SCHEDULE. 

Defining  defdass  block  POSTURE 

Defining  deffunction:  Call-Guidance-W^pcmt 

Defining  deffunction:  Gall-Guidance-Coinmand 

Defining  deffunction:  Rqdan-Route 

Defining  deffiinction:  Abort-Route 

Defining  definstances  block  STARTING  J>ECISIONS 

Defining  deffacts:  Starting_Facts 

Defining  defrule:  initialiae-vdiicle  tj 

Defining  defrule:  iqdoad  tHtH 

Definiiv  defrule:  Mission_Timer  -»j 

Defining  defrule:  timer-manager  -»-j 

Defining  defrule:  DoGunient;_Mission  -fj 
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Defining  defrule:  eventjBd)edule_nianager 
Defining  deffiinction:  Tocal'Functional-Problems 
Defining  defrule:  OveraU_Mission.^Asse8Sor 
Defining  defrule:  Continue-Mission_unre8ttkted 
Defining  defrule:  Continue-inission_iestricted-update  tH 
Defining  defrule:  Condnue.misaonjrestikted Jnitial 
Defining  defrule:  AboruMitsion 
Defining  deffiinction:  di^lay-status 
Defining  defiule:  sbow_stahis_boeid 
CL1PS>  (lend  nianeuvering.clp) 

Defining  defj^obal:  *noaneuver_salienoe* 

Defimng  defglobal:  *obstacle_Tef* 

Defining  defglobal:  *ot)stacle_cleaianoe_time* 

Defining  defglobal:  *avddanoe_time* 

Defining  defglobal:  ^nuuieuvefability.factor* 

Defining  defclass  block  OBSTACLE 

Defining  deftnessage-handler  obstacle-change  prinuny  in  class  OBSTACLE. 
Defining  defrule:  Maneuvering_Status_A««essrnent  titH 
Defining  defrule:  Maneuvering_Status_Assessinent_long_jange 
Defining  defrule:  Maneuvering_Equipfnent_Failure  -fj 
Defining  defrule:  emeigency_maneuver_evaluation  4j 

+j 

Defining  defrule:  Assess_Avoidanoe_Maneuver 
Defining  defrule:  emergency-evasive-nianeiiver-ascend  43 

+j 

+j 

+j 

Defining  defrule:  emeigency-evasive-nianeuver-leftascend  4-j 
Defining  defrule:  emeigoicy-evasive-inaneuver-left  -fj 
Defining  defrule:  emergency-evasive-nuuieuver-ri^tascend  -f j 
Defining  defrule:  emeigoicy-evasive-maneuver-right  -fj 
Defining  defrule:  emeigency-evasive-nuuieuver-stopascend  4j 

+j 

Defining  defrule:  abnomud.surface 

rH+j 

Defining  defrule:  abnoinial.ascent 
•  •  • 

Defiiting  defrule:  abnonnal_dive 
*  *  >  * 

Defining  defrule:  Obstacle J)eiection_hk>nnalJJniits  4j4j 
Definh^  defrule:  Obstade.UpAue 
Defining  defrule:  C(tilective_Ot»tacle_Assessnient  4-j 
CLIPS>  (load  navigation.clp) 
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Uilinipg  OBiyOWI  ItSVff  lUWBUK* 


HfHniag  dcfj^obtl:  *iiivifiiioic.sdicBoe* 

Definiiig  defn^nhil:  *tafejdq^* 
ucfiimn  flapopti;  ^ponoBiUPwicit  i  mbc^ 

Defin^  defij^obal:  ^toooiiLPbitadejawJiiierv^ 
Defining  defrule:  N«vigntion_AMessineitt  •f/fj 
^3 

Defining  deftulc:  N«vigMk»i.A«wMaaei^_BquqMnem4j4j 


Defining  defhde:  OonLficoognkion  tH 

Defining  defifide:  Wty|X)imAmval>DepdCbaa|)«ifoo<kMlCI^  tHtJ 

Defining  deftule:  Wnypoinunniilor 

Defining  defruk:  WaypoinU[>iMnoeTimeEneigy_Clieck 

Defining  defrule:  Tinie_Deviation  *f  j 

Defining  defrule:  dq)di^soandingjkviation_diort_iange  ag 

■i 

■i 

Defining  defrule:  dq)di_soundingjdeviation_long_nuige  aj^ 

Defining  defrule:  DMect.Shoaling  4j 
CLIPS>  (load  lentorx^) 

Defining  defglobal:  *tywnoniior,i«lieace* 

Defining  defglobal:  *QQrEqn4iineaiJifiled* 

Redefining  defglobal:  7*>hWavlnitniment8failed* 

Defining  defglobal:  *NfSonarfnled* 

Defining  defflobal:  *NAnvironSensonfiuled* 

Defining  defdau  Mock  SYSTEM_MONnt)R 
Defining  deftdau  blocfc  POWER_SOURCE 

Defining  definenage-handlcr  getneading  after  in  dass  POWER_SOURCE. 

Defining  defdass  blocfc  SONAR 

Definn^  defrneseage-haidler  get-feading  after  in  dasi  SONAR. 

Definiag  deldau  blodc  NA  VIQATION JNSTRUMENT 

Defii^defriieiiage-liandler  get-feading  after  in  dass  NAVIGATION  JNSTRUMENT. 
Definiag  defclaas  blocfc  OONTROl^YSTEM 

Defiaiag  definesaage-tendler  gei-ieading  after  in  dan  OONTRCX^SYSIEM. 


Defining  defdan  blocfc  ENVIRON_SENSORS 

Defij^drftneiiagc  handWget-readii^  after  in  dan  ENV1RONJ5ENSORS. 
Definb^defineange-handler  get-environmeittaljeading  after  in  dan 
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ENV]RON_SENSORS. 

Defimnfdefcltts  block  MISSK»fJBQUlPMENT 

PefiirinfdcfmwMgr-handlerfet-TOiding  after  in  class  MISSION JBQUIPMENT. 

PefiiiMndefinitanccia  block  Sytmooiior-Bairic 

Defiaiiif  deftuk:  iiioiiiiorJhealilL.ooittiimoiisly  -tj 

DdRung  defruk:  clwckjaiticaL«|uq)inent  ti 

Defioinf  defrvle:  E(piqiineiMLStatus.>aaes«aient 

TlTITlTI 

Defining  deftule:  EquqimeniLReooveiy  -tj 
Defining  defrule:  Fower_Sooeoe_Qitical  tHtl 
Defining  defivle:  SomBL^dhne  tj 
Defining  definie:  Sooar.Oritical  t) 

Defining  deftnk:  NavigatkxLbstnnnencFcibne 
Defining  deftule:  Cooiiol_Syi(eai_Ontical  4j 
Defining  defrule:  Conotd_Sysiem_Failure  tl 
Defining  deftule:  Enviraninental.Sensor_Failure  4j 
CLIPS>  (load  envifoomenLc4>) 

Defining  defglobal:  *cnviiDnment.galienoe* 

Defining  defglobol:  *QtyEnvironProblems* 

Defining  defglobal:  *iee_staie_diresh* 

Defining  deftule:  EnvifonmenLAsaesaor 

Defining  deftule:  Enviionment_Assessor_E<luipP>ent  4j-fj 

Defining  defrule:  atiioide.aensar  4-j 

Defining  defrule:  piesiure_aensor 

Defining  defrule:  tenveramrejKnsor  4-j 

CLIPS>(feiet) 

CLIPS>(run) 


Welcome  lo  the  MISSiQN  EXECUTOR  DEMO 

WAYPOINTS:  All  icenarioc  take  plaoe  over  the  same  aet 
of  INITIAL  waypoint  oooitfnaies. 

EC^JIPMENT:  Afi  e(p#meat  to  sinanlased  in  the  event  file 
Objects  are  creai^  for  each  onboard  equipment 

STTUATKWS:  All  ntuatioos  are  also  ritnulatrd  in  the  event 
file.  For  instance,  an  obstacle  detectioii  is 
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Ktted  md  dlit  ifandiM  die  Otaiicle  AYoidnoe 
DedsiooMiker  pasw^  thU 
tfie  interftKx  to  the  Executor . 

SCENARIO  QKXCES:  idectiiiiml)cr^lei> 

1  Wi^poinUfiopiMiif  Only  (trai^ 

2  Obiade  Avoidance 

3  VddcleCoiMiol  System  FiiliTO 

4  Obsiades  and  Environment  RtoUems 

5  Equipment  FaUmes 

6  Exit  die  Simulator 


1 

»»»»»»  Decision  «««««« 
9pe  :  Navifadon 

:  WaypotntAfxival-DqidiGonq»iison 
level  :  Lofwjusessment 
action:  detennine_type_<rfL.dq}di_change 
time  :  0.232 


»»»»»»  Decision  «««««« 
qrpe  :  Navifaiion 

:  Waypoint_PistanceTinie_.C}ieck 
level  :  Lowjuaessment 
acdon:  deaemiiiieJf_need_to_increase.qpeed 
time  :  a407 


»»»»»»  Decision  «««««« 

qrpe  :  Navigation 

nte  :  WqrpoiniLnionitor 

level  :  Lomjuaeuman 

action:  assess jsext_waypoint_aadLaequence 

time  :  0J69 


I  Skipper's  Disptey  I 


TDiffi  inn^secs  OKX) 

Ovendl  Mteion  Status  »»  Goniinue_Unrestiicted  «« 
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Mantievering_Status :  unrestricted 
EquqmieniLStatus  :  nomud 
Navifiik»_Statu8  :  within_tolerance 
Enviroiiinent.stitus :  normal 
Spec_Mission_stanis:  feasible 

- 1 

I  evtriutkm  :  transit 
I  dqMh-status  :  dive 

1 1401  Coomiand  tt>  Guidance :  underway 
I  enroute-waypoint  :  1 


I  Obstacles  I 


I  Direction  I  Proximity  (Type  I 


EQUIPMENT  DOWN  I 


Event  Number:  1 


Description:  passing_waypoint 


Time  :  10.000 


I*** 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rule  :  WaypointArtival-DepthConqrariscm 
level  :  Low.assessment 
action:  detennine_type_of_dq>th_change 
time  :  10.207 


»»»»»»  Decision  «««««« 


:  Navigation 

:  Waypoint.DistanceTime_Check 
level  :  Low^assessment 
action:  deierminejf.need.tojncrease  speed 
time  :  10.380 
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»»»»»»  Decision  «««««« 

^pe  :  Navigation 

rale  :  Waypoinumonitta* 

level  :  Low_assessinent 

action:  assess_next_waypoint_and_sequence 

time  :  10J43 


Skipper's  Di^lay  I 


TIME  in  niin_secs  0:10 

Overall  Mission  Status  »»  Oondnue.Umestricted  «« 
Manuevering_Stabis :  unrestricted 
EquipmentLStatus  :  normal 
Navigation.Status  :  within.tolerance 
Environment_status :  normal 
Spec_Mission_status:  feasible 

levtdution  :  transit 
I  dq;»th*status  :  dive 

I  Last  Command  to  Guidance:  mark_on_tt^ 

I  enroute-waypoint  :  2 


Obstacles  I 


I  Direction  I  Proximity  I  Type  i 


I  EQUIPMENT  DOWN  I 


Event  Number:  2 


Desoiption:  passing_waypoint 
Time  :  38.000 


»»»»»»  Decision  «««««« 
type  :  Navigation 


ISO 


lule  :  WaypointAirival-DepthConqMrison 
kvd  :  Low.assessiiiem 
action:  dMeimine_type_of_depth_.change 
time  :  38^68 


»»»»»»  Decision  «««««« 
^pe  :  Navigation 

ntie  :  WaypmntJDistanceHme.Clieck 
level  :  Low.assessment 
action:  detenmne.if_nee(LtD_inciease_q)eed 
time  :  38.444 


»»»»»»  Decision  «««««« 

type  :  Navigation 

role  :  Waypoint^monitor 

level  :  Low.asaessment 

action:  asaess_next_waypQint_and_sequence 

time  :  38.607 


I  Skipper's  Diq>lay  I 


TIME  inmin_8ecs  0:38 

Overall  Mission  Status  »»  Gontinue.Umestricted  «« 
Manaevering_Status :  unrestricted 
Equ4xnent_Status  :  normal 
Navigation_Status  :  within^tderance 
EnvironmeniLStatus :  normal 
Spec_Misaon_stattts:  feasible 

- 1 

levdution  :  transit 
I  dqxh-status  :  dive 

t  Last  Command  to  Guidanoe:  maik_on_top 
I  enroute-waypdnt  :  3 


I  Obstacles  1 


I  Infection  I  Praodmity  I  Type  I 
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I  EQUIPMENTDOWN  I 


*4>**i»****4t***«**************4t*****4t**«4>*****«** 

Event  Number :  3 
Description:  passing_waypoint 
Time  :  107.000 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  WaypointAirival-DqithComparison 
level  :  Low_assessment 
action:  detennine_type_of_dq)th_change 
time  :  107^76 


»»»»»»  Decision  «««««« 
type  :  Navigation 

niJe  :  WaypointJDistanceTime.Check 
level  :  Low.assessmem 
action:  deiennine_if.need.to_increase_speed 
time  :  107.456 


»»»»»»  Decision  «««««« 

type  :  Navigation 

nde  :  Navigation_Assessment 

level  :  Assessment 

action :  detennine_Nav_Status_and_pass_to_C>verall_Mission_assessor 
tinne  :  107.620 


»»»»»»  Decision  «««««« 

type  :  Navigation 

nJe  :  WqrpoiniLmonitor 

level  :  Low.assessment 

action:  aaaess_next_waypoint_and_sequence 

time  :  107.781 
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Skipper's  Di^lay 


TIME  iniiiin_secs  1:47 

Overall  Mission  Status  »»  Continue.Unrestricted  <<« 
Manuevefing_Status :  unrestricted 
EquqnDencStatus  :  normal 
Navigation_Status  :  within_tolCTiuice 
Envitoniiient_status :  normal 
Spec_Mission_status:  feasible 

- 1 

levtrfution  :  transit 
I  dqnh-status  :  no-dq)th-change 

. . . . . - - 

I  Last  Command  to  Guidance:  maik_on_t(^ 

I  emoute-waypoint  :  4 


I  Obstacles  I 


I  DirectitMi  I  Proximity  I  Type  I 


I  EQUIPMENT  DOWN  I 

*****«*********4>**i|i««*******4i4i**4i*4i*****4>****** 

Event  Number:  4 


Description :  passing_waypoint 
lime  :  125.000 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rule  :  WaypointArrival-DepthComparison 
level  :  Low_assessnient 
action:  dMetmine_type_of_depth_change 
time  :  123^32 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rule  :  Waypoint_Distance71nie_Check 
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level  :  Low.assessroent 

action:  detennine_if_need_to.incfease_q)eed 

time  :  12S.41S 


I  Skipper's  Display  I 


TIME  inimn_secs  2:05 

Overall  Mission  Status  »»  G>ntinue_Uniestricted  «« 
Manuevering_Status :  unrestricted 
Eqtii|ni]enL.Status  :  nonnal 
Navigation_Status  :  within_tolerance 
Envir(Miiiiait_status :  normal 
Spec_Missi(Hi_status:  feasible 

(evolution  :  transit 
I  depth-status  :  no-depth-change 

I  . . . ,, 

I  Last  Command  to  Guidance :  Increase-Speed 
I  enioute-waypoint  :  4 

I  C^stacles  I 


I  Direction  I  I^ximity  (Type  I 


EQUIPMENT  DOWN 


»»»»»»  Decision  «««««« 

type  :  Navigation 

rule  :  Wayp(nnt_roonitor 

level  :  Low.assessment 

action :  assess.next.waypoint.and.sequence 

time  :  126.153 


Event  Number:  5 


DescriptitHi :  passing_waypoint 
Time  :  145.000 
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**********4i**4i*********«***«***t|i**«************ 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  WaypointAnival-DepthCoaq)arison 
level  :  Low_assessiiiem 
action:  detennine_type_of_dq)th_change 
time  :  145.203 


»»»»»»  Decisicm  «««««« 
type  :  Navigation 

rale  :  WaypoinLDistanceTime.Check 
level  :  Low^assessment 
action:  deterniine_if_need_to_increase_q)eed 
time  :  145.388 


»»»»»»  Decision  «««««« 

type  :  Navigation 

rale  :  Waypoint;_monitor 

level  :  Low_assessment 

acticHi :  assess_next_waypoint_and_sequence 

time  :  145.551 


I  Skipper’s  Di^lay  I 


TIME  inmin_secs  2:25 

Overall  Mission  Status  »»  Continue.Uniestricted  «« 
Manuevering^Status :  unrestricted 
Equiimient;_Status  :  normal 
Navigation.Status  :  within.tolerance 
Environment_status :  nrnmal 
Spec.Misskm.status:  feasible 

levtriution  :  qiecimss 
IdqMh-status  :  no-dqKh-change 

i  L4at  Command  to  Guidance :  mark_on_mp 
I  ououte-waypoint  :  6 


I  Obstacles  I 
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I  Doection  I  ftoxiinity  I  Type 


EQUIPMENTDOWN  ( 


«***4i*«***4i***4i****4i*4i4i**4i*4<4i*4i*4t*4i4i***4i*4i4i4i4i** 

Event  Number :  6 


Description:  passing_waypoint  < 


Time  :  167.000 

4i«*«********«*«*4i*4i****«**«*«4i***«4i***4i*****»** 

»»»»»»  Decision  «««««« 
type  :  Navigation 

nile  ;  Wayp(»ntArriva]-Dq)thComparison 
level  :  Low_assessment 
action :  determine_type_of_depth_change 
time  :  167.201 


»»»»»»  DecisicHi «««««« 
type  :  Navigation 

rule  :  Waypoint.Distance'nme.Check 
level  :  Low.asaessment 
action :  det6rmine_if_need_toJncrease_q)eed 
time  :  167.391 


»»»»»»  Decision  «««««« 

type  :  Navigation 

rale  :  Waypoint.monitor 

level  :  Low.assessment 

action :  as8ess_next_waypoint_and_seqiwnce 

time  :  167.354 


Skippei^s  Di^lay  I 


TIME  in  min_8ecs  2:47 

Overall  Mission  Status  »»  GmtinueJLJnrestricted  «« 
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Manueveriiig_Statas :  unrestricted 
EquqHnent_Status  :  nonnal 
Navi^on_Status  :  within^tolenuice 
EnvirooineniLstatus :  nonnal 
Spec.Mission_status:  feasible 

- 1 

levtriution  :  qteciniss 
I  dqxh-status  :  ascent 

I  Last  Command  to  Guidance :  maik_on_top 
I  emoum-waypdnt  :  7 


I  Obstacles  I 


I  DirectitMi  I  Proximity  (Type  I 


EQUIPMENT  DOWN  I 


Event  Number:  7 


Description:  passing_waypoim 


Time  :  175.000 

»»»»»»  Decision  «««««« 
Qrpe  :  Navigation 

nile  :  WaypointAirival-DepthComparison 
level  :  Low.assessment 
action:  detennine_type_of_depth_change 
time  :  175.227 


»»»»»»  Decision  «««««« 
Qrpe  :  Navigation 

role  :  Waypoint_DistanceTime_Check 
level  :  Low.assessment 
action:  detennine_if_need_to_increase_speed 
time  :  175.418 
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»»»»»»  Deciskm  «««««« 
9pe  :  Navigation 

:  WaypoinLinonitor 
levd  :  Low^assessmem 
action:  assess_next_wayp(^t_and_sequenoe 
time  :  175J83 


I  Sldppei's  Di^lay  I 


TIME  iniiiin_8ecs  2:55 

Ovenll  Mission  Status  »»  Continue.Uniestricted  «« 
Manuevoing^Status :  unrestricted 
Equqm)ent_Status  :  normal 
Navigation_Status  :  within_tolerance 
Environment_status :  normal 
Spec_Mission_status:  feasible 

- 1 

(evolution  :  transit 
I  dqjtlHstatus  :  ascent 

I  Last  Command  to  Guidance:  mark_on_t(^ 

I  enroute-waypoint  :  8 


I  Obstacles  ( 


I  Direction  I  Proximity  (Type  I 


I  EQUIPMENT  DOWN 


Event  Number:  8 
Description :  passing_waypoint 
lime  :  196.000 


»»»»»»  Decision  «««<««< 
type  :  Navigation 


158 


role  :  WaypointAmval-DqpthCoiiq)arison 
level  :  Low_asse8sinent 
action:  detBnnine_type_of_depth_duuige 
time  :  196.219 


»»»»»»  Decision  «««««« 
type  :  Navigation 

:  WaypoinLDistancellnie.Check 
level  :  Low_assessmait 
action :  detennine_if_need_to_increase_q)eed 
time  :  196.415 


»»»»»»  Decision  ««««««: 

type  :  Navigation 

rale  :  Waypoint_monitor 

level  :  Low_as8essment 

action:  as8ess_next_waypoint_and_sequence 

time  :  196.580 


Skinier’s  Di^lay  I 


TIME  inmin_secs  3:16 

Overall  Mission  Status  »»  Continue.Unrestricted  «« 
Manuevering_Status :  unrestricted 
Equipment_Status  :  normal 
Navigation_Status  :  within_tolerance 
Environment_status :  normal 
Spec.Mission.status:  feasible 


I  evolution  :  tranat 
I  deptii-status  :  surface 

I  Last  Connmand  to  Guidance :  maik_on_t(^ 
I  enroute-waypmnt  :  9 


Obstacles  I 


I  Direction  I  Proximity  (Type 


I  EQUIPMENTDOWN  I 


Event  Number :  9 


Deicripikm:  iMssing_wiypoiiit 
Ttoe  :  21OJ0OO 


»»>Made  it  to  Ootl«««< 

At  time :  2ia03ti0000000001 

1836S  rales  fired  Run  time  is  2112829999999994  seconds 
86.S1 187330120663  rales  per  second 
16  mean  number  of  facts  (20  maximum) 

2  mean  number  of  activations  (S  maximum) 

CL1PS>  (dribble-off) 
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2.  SCENARIO  2 


CLIPS>  (walch  statistics) 
CLIPS>  (baidi  iqrioad-bat) 
CLIPS>  (ckMc) 

FALSE 
CL1PS>  (clear) 

CL1PS>  (load  sld|iper.c^) 
CL1PS>  (load  iiiuieiiveriiig.c^) 
CLIPS>  (toad  naivigatioiLC^)) 
CL]PS>  Ooad  aensorxl^) 
CUPS>  (load  eoviroomenLc^) 
CLIFS>  (reset) 

CLIPS>(nin) 


Welcome  to  the  MISSION  EXECUTOR  DEMO 

WAYPOINTS:  All  scenarios  take  place  over  die  same  set 
of  INITIAL  waypoint  coonhnates. 

EQUIPMENT:  All  equqment  is  smnilated  in  the  event  file 
Objects  are  cieai^  for  each  onboard  equipment 

SITUATIONS:  All  situations  are  also  shnniated  in  the  event 
file.  For  instance,  an  obstacle  detection  is 
Ksied  and  this  simulates  the  Obstacle  Avoidance 
DecisionMaker  passing  diis  information  throu^ 
die  interfiioe  to  the  Executor . 

SCENARK)  CHCMCES:  sdect  nundier  <Ret> 

1  WsypointJioppinf  Only  (transit) 

2  Obsiade  Avoiitance 

3  V^ide  Control  System  Fulnte 

4  Obstacles  and  Environment  ftoUems 

5  Equipment  Faitates 

6  Exit  the  Sinnlaior 
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»»»»»»  Decision  «««««« 
type  :  Ntvipiion 

rale  :  WqrpointAmvil-DqidiOompiiii<oa 
level  t  LowjMsement 
action:  detenninf._type_of_depth_change 
time  :  0^7 


»»»»»»  Decision  «««««« 
Qrpe  :  Naviptioo 

nde  :  WaypointJ)istHioeTime_ChedE 
level  :  Low_assesanent 
action:  deiennine_if_need_tD_inciease_speed 
time  :  0.423 


»»»»»»  Decision  «««««« 

type  :  Navifation 

nie  :  Wqfpointjiioniiar 

levd  :  Lowjasaesment 

action:  asae»_iie3(ijiraypointjuid_seqiieace 


Skippei'sDispUy 


TIME  mmiiL.secs  OKiO 

Overall  Miasion  Statns  »»  Gontiniie.Umestricted  «« 
Mamirvrrint^Stann :  umesiricted 
BqoipineiicStatus  :  nonnal 
NaviiatiQit_Staiiis  :  edMnjtcknace 


Spec jMisaioo_stttos:  feasible 


I 


Obstacles 


I 


I  Directioii  I  Proximity  I  Type  I 


I  EQUIPMENT  DOWN  I 


Event  Number :  1 


Description:  passing_waypQint_l 


Time  :  10.000 


»»»»»»  Decision  «««««« 
Qrpe  :  Navigation 

rale  :  WaypointAnival-DepthComparison 
level  :  Low_assessment 
action:  detennine_type_of_dq)th_change 
lime  :  10.193 


»»»»»»  Decision  «««««« 
Qrpe  :  Navigation 

rale  :  Waypoint_Distancellme_Check 
level  :  Low_assessment 
action:  deteimine_if_need_to_inciease_q)eed 
time  :  10.368 


»»»»»»  Decision  «««««« 
type  :  Navigation 

:  Waypoint_moniior 
level  :  Low_assessment 
action:  assessj)ext_waypoini;_and_sequeooe 
time  :  10J31 
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supper's  Display 


TIME  inmiiLJncs  (hlO 

Ovcnll  Missian  Status  »»  Continue.Unrestricted  «« 
Maiiiieivering_Status :  unrestricted 
EquipiiienL.Status  :  normal 
Navigation_Status  :  widun.tolerance 
Enviroiuiient_status :  normal 
Spec_MissioQ_saaus:  feasible 

- 1 

I  evolution  ;  transit 
I  dqxh-status  :  dive 

I  Last  Command  to  Guidanoe :  mark_on_top 
I  emouie-wayptmt  :  2 


I  Obstacles  I 


I  Direction  I  Proximity  I  Type  I 


I  EQUIPMENTDOWN  I 


Evait Number:  2 


Description :  passing_wayp(mc2 


Time  :  20.000 


»»»»»»  Decision  «««««« 
9pe  :  Navigation 

rule  :  WiypointAiiival-DepthComparison 
level  :  Low^assessment 
action:  delermine_type_of_dq)di_change 
tune  :  20.627 
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»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  WaypdntDistancellme.Check 
levd  :  Low_asse8siiient 
aoion:  deieniiine_if_need_to_increa8e_speed 
time  :  20.804 


»»»»»»  Decision  «««<««< 
Qrpe  :  Navigation 

:  Wi^pointunonitor 
level  :  Low_assessment 
action:  assess jnext_waypoinuand_sequeoce 
time  :  20.968 


I 


Skippei^s  Di^lay 


I 


TIME  inmin_secs  0:20 

Overall  Missioo  Status  »»  Continue.Unrestricted  «« 
Mantievering_Status :  unrestricted 
Equ^imeniLStatus  :  normal 
Navigaiion.Status  :  widiin^iolerance 
Enviroiuiient_status :  normal 
Spec_Mission_statos:  feasible 


transit 
;  dive 


I  evolution 
I  dqith-status 

I  Last  Command  to  Guidance :  maik_on_u>p 
i  emoute-wayprant  :  3 


I 


Obstacles 


I 


I  Dffection  I  Proximity  llVpe 


EQUIPMENT  DOWN 
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*••••••***•*»«*•***••••***••••• 

Event  Number :  3 

Description:  obstacles_close_aboaid 
Time  :  27.000 


»»»»»»  Decision  «««««« 
type  :  Maneuvering 

nite  :  emergency-evasive-maneuver-asoend 
level  :  Low-siqNSiviaaiy-level 
action:  asoendLtt>_avokLobstacle 
time  :  27^2 


i  Skipper’s  Diqilay  I 

TIME  inmin_aecs  0:27 

Overall  Mission  Status  »»  Continue.Umestricted  «« 
Manuevering^Status :  unrestricted 
Equq^nt_Status  :  nonnal 
NavigatioiL.Status  :  widiin^tolerance 
Enviroament_status :  nonnal 
Spec_Misrion_status:  feasible 

- 1 

I  evolution  :  transit 
I  dqtth'Status  :  dive 

I  Last  Command  to  Guidanoe :  ascend-?*safe_depth* 

I  emoute-waypoint  :  3 


I  Obstacles  I 


I  Direction  I  Ptoximity  I  Type  i 


I  EQUIPMENTDOWN  I 
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»»»»»»  Decision  «««««« 
type  :  Maneuvering 
rale  :  emergency_maneuver_evaluation 
level  :  assessment 

action :  assess_emeigency_obstacle_avoidance_nuuieuvers 
time  :  28.704 


Event  Number:  4 


Description:  passing_waypQint_3 


Hme  :  33.000 

*4i**********4i***4i******4i****««*4i4i4i4i*****4i4i**4i** 

»»»»»»  Decisicm  «««««« 
type  :  NavigaticMi 

rule  :  WaypointAirival-DepthComparison 
level  :  Lowjusessment 
action:  detennine_type_of_depth_change 
time  :  33.201 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  Waypoint.Distancellme.Check 
level  :  Low_assessment 
action :  detennine_if_need_to_increase_speed 
time  :  33.380 


Skipper’s  Display  I 


TIME  inmin_secs  0:33 

Overall  Mission  Status  »»  Continue.Unrestricted  «« 
Manuevering_Status :  unrestricted 
Equipment_Status  :  normal 
Navigation_Status  :  within.tolerance 
Enviionment_status :  ntMinal 
Spec_Mission_status:  feasible 

I  evolution  :  transit 
I  depth-status  :  dive 

I  Last  Comnaand  to  Guidance :  Increase-Speed 
I  ououte-waypoint  :  3 


Obstacles  I 


I  Direction  I  Proximity  I  Type  I 
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EQUIPMENT  DOWN 


»»»»»»  Decision  «««««« 

type  :  Navigation 

nile  :  Wayptmtjmmutor 

level  :  Low_assessment 

action :  assess_next_waypoint_and_sequence 

time  :  36.133 


Event  Number:  5 


Description :  obstacle_detected_at_nonnal_range 
Time  :  41.000 

4i4i*4i*********4i*«*«4i4i4i4i***4>««*4i4i4<4t*««iii«***4i***4i« 

Event  Number:  6 


Description :  obstacle.classified.as.new 


Tme  :  41.000 

*****4i«4<4i****4i*4i4i4i4i4i4ii»4t4i4i**4i4i4i*4i*4i4t***4i***4i4i4t4t4t 

»»»»»»  Decision  «««««« 
type  :  Maneuvering 

rale  :  Obstacle_detection_Normal_Limits 
level  :  Low.assessment 
action :  classify_n(xmal_range_d>stacle_as_new 
time  :  41.439 


»»»»»»  Decision  «««««« 
type  :  Maneuvering 

:  Oollective_Obstacle_Assessment 
level  :  Low.assessment 

action :  assess_whedier_presents_a_coUision_danger_and.tum 
time  :  41.650 


d 
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»»»»»»  Decision  «««««« 

^ype  :  Minoivering 

nik  :  Maneiivering_Status^88essiDent 

level  :  meneiivefing-assessinent 

action:  chan^-oveiall-nianeuvering-status 

time  :  41.817 


»»»»»»  Decision  «««««« 
type  :  Ovefill_Mission 
nile  :  Ovefall_Mission_Assessor 
level  :  High 

action :  ContinueMission_withjrestrictions 
time  :  41.988 


»»»»»»  Decision  «««««« 

type  :  Ovenll_Mis8ion 

nie  :  Continue_mission_iestricted_initial 

level  :  Assessmoit 

action:  Note-tune-of-status-change 

time  :  42.149 


^*4i**4>*4i****** 


Event  Number:  7 


Description:  obstacle_detectBd_at_nonnal_range 


Time 


41.000 


Event  Nuiiri)er :  8 


Description:  obstacle_classified_as_new 


Time  :  41.000 


»»»»»»  Decision  «««««« 
type  :  Maneuvering 

nile  :  Ob8tactejdetection_N(xinalJLiimts 
level  :  Low_assessiiient 
actkxi:  classify_nofnial_range_obstacle_as_new 
tune  :  42.786 


Event  Number:  9 

Description:  obstacle_detected_at_nocinal_iange 
Time  :  45.000 

*******4i***4>*4>****4i4i4i*4i**i|i**4i*4i4i*4>*4i4t****4i***** 

Event  Number:  10 


Descriptimi :  obstacle.classified_as_new 


Time  :  45.000 

*4i*4i**4i«**4i**4i«*t|t*4i4i4i«***<|i*«i4i*****«****4i4i**4i*4i* 

»»»»»»  Decision  «««««« 
type  :  Maneuvering 

rale  :  Obstacle_detection_Normal_Liinits 
level  :  Low.assessment 
action:  classify.mnmal.range.obstacle.as.new 
time  :  45.453 


************4t***************4t4i***)|i*«*****«**4t4>* 

Evoit  Number:  11 


Description:  obstacle_detected_at_nofmal_range 
Time  :  50.000 


Event  Number:  12 
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DeKrqMkm:  obstacle_cl«ssified_as_new 
Tinie  :  SO.OOO 


»»»»»»  Decision  «««««« 
type  :  Maneuvering 

:  Obstacte.detecrion J*<ormal_iiinits 
level  :  Lowjusessment 
action:  classify.nQnnaLjrange_obstacle_as.new 
time  :  50.452 


»»»»»»  Decision  «««««« 
fype  :  Maneuvering 

:  Maneuvering_Status_Assessment 
level  :  maneuvering-assessmem 
action:  change-overall*maneuvering-status 
time  :  57.079 


»»»»»»  Decision  «««««« 

type  :  OveraU.Mission 

rale  :  Ovenll_Mission_Assessor 

level  :  Hi^ 

action:  AboctLmissicm 

time  :  57J151 


»»»»»»  Decision  «««««« 
type  :  OveFaU_Mission 
rale  :  AbQrt_Misskm 
level  :  Low 

action:  lock_status_and_rq)lan_route_to_aboit_iendezvous 
time  :  57.407 


»»»»»»  Decision  «««««« 
type  :  Navigttion 

:  WaypointAirival-DepdiGonqMrison 
level  :  Low_as8esament 
action:  deieraiine_Qfpe_of_depth_change 
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time  :  57.718 


»»»»»»  Decision  «««««« 
lype  :  Navigation 

rule  :  WaypmntJTistanceTliiie.Check 
level  :  Low_assessment 
action:  detennine_if_need_to_inciease_q)eed 
time  :  57.891 


»»»»»»  Decision  «««««« 

type  :  Navigation 

nik  :  Waypoint_monitor 

level  :  Low_assessment 

action:  assess_next.waypoini_and_sequeiKX 

time  :  58.055 


I  Skipper's  Di^lay  I 


TIME  inmin_secs  0:57 
Overall  Mission  Status  »»  Abort.mission  «« 
Manuevering_Status :  severelyjrestricted 
Equipment_Status  :  normal 
Navigation.Status  :  within.tctienuice 
Environment^status :  normal 
Spec_Mission_status:  feasible 

{evolution  :  aborutransit 
I  depth-status  :  no-depdi-change 

I  Last  Command  to  Guidance:  mark_on_tc^ 

I  emoute-waypoint  :  1 


I  Obstacles  I 


I  Direction  I  ntoximity  llVpe  t 


89.0  far  floming 

356.0  fer  floating 
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I  EQUIPMENTDOWN 


I 


*********«******4 

Event  Number :  13 


Description:  maritjon_aborcwayp(mt 
Ttoe  :  77.000 


»»»»»»  Decision  «<««««< 
qrpe  :  Navifition 

nde  :  WayprantAnival-DepdiComparison 
level  :  Low_asse8sment 
action:  detenmne_type_of_dq>th_chan^ 
time  :  77.199 


»»»»»»  Decision  «««««« 
Q^ie  :  Navigatitxi 

rule  :  WaypointJDistance'nme.Check 
level  :  Low.assessment 
action:  deieimine_.if_need_to_increaae_q)eed 
time  :  77.375 


»»»»»»  Decision  «««««« 

9pe  :  Navigation 

rite  :  Waypoiitt^monitor 

level  :  Low_assessment 

action:  assess_jiext_waypoint_and_aeqoenoe 

time  :  77.539 


Skipper's  Display  I 

TIME  iaiBin.secs  1:17 
OvcraD  Mirnkm  Statn  »»Ab(xonissioo«« 
MaBfvcring_Simus :  8everdy.jestricied 
EqnipmeoiC.StBtttS  :  normal 


Enviromnenustatus :  nonnal 
Spec_Missioii_statiis:  feasible 


levoliitioii  :  abort.transit 
I  dqxh-stattts  :  ascent 

I  Last  Gommand  to  Guidance:  transiting_to_aboii;_iendeavoiis 
I  enioute-waypoint  :  2 


I  Obstacles  I 


I  Direction  I  Proximity  I^Type  I 


89.0  far  floating 

336.0  far  floating 


I  EQUIPMENT  DOWN  I 


*«««***«***««*****4i*««**«*«*4i«**4i*«***4i«*«i**4i** 

Event  Number:  14 

Description :  niaric_on_abort.wayp(mt 


Tune  :  98.000 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rule  :  Wayp(»ntAirival-Dq)thConqMrison 
level  :  Low_r«  lessment 
action :  deiernane_type_of_dq)th_diange 
time  :  98.230 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rule  :  WaypoiiilJ>isianceTime_Check 
levd  :  Low_Mses«nent 
action:  deienitine_if.need_io.increase_speed 
time  :  98.406 
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Ill’ll 


»»»»»»  Decision  «««««« 

:  Navigatkm 
WaypoiniLinonitor 
:  Low_as8essinent 

:  assessjiexuwayp(mt_and_sequence 
:  98370 


I  Skipper's  EHqiUy  I 


TIME  uiimQ_tecs  1:38 
Overdl  Missioo  Status  »»  Aboconission  «« 
Manaevefing_Status :  severelyjrestricted 
EquqMnenuStatus  :  normal 
Navigation_Status  :  within_tolerance 
Environment_status :  normal 
Spec_Mission_status:  feasible 

- 1 

I  evrriution  :  abort_transit 
I  depth-status  :  ascent 

i  Last  Gormnand  to  Guidance :  underway 
I  enroute-waypoint  :  3 

I  Obstacles  I 


I  Direction  I  Proximity  I  Type  I 

89.0  far  floating 

356.0  far  floating 


I  EQUIPMENTDOWN 


I 


Event  Number :  15 


Desaiptkxi:  maflL.(m-abort;_wayp(mt 
lime  :  112.000 


>»»»>»»  Deciskm  «««««« 
9pe  :  Naviption 

:  WaypointAnival-Dq>thGomparis(m 
level  :  Low^asaessment 
action:  detenmiie_type_(rf_dq>th_change 
time  :  112.246 


»»»»>»>  Decision  «««««« 
type  :  Navigation 

nile  :  Waypoint.Distance'nme.Check 
level  :  Low_assessment 
action:  determine_if_need_tOL.increase_speed 
time  :  112.425 


»»»»»»  Decision  «««««« 

type  :  Navigation 

rale  :  Waypoint_monitCN: 

level  :  Low.assessment 

action:  asaess_next.wayp(nniLand_sequence 

time  :  112.589 


i  Skqtper's  Di^lay  I 


TIME  inmii|_secs  1:52 
Overall  Mission  Status  »»  Aboctjnissioa  «« 
Manuevcriag_Status :  seveiely_iestrictBd 
EtpnpmencStatus  :  nonnal 
Navigation_Stttus  :  witiiinL.txtierance 
EmnranmenLttatus :  nonnal 
Spec.Mission_statiis:  feasible 
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I  evobitioii  :  abon_tnuisit 
I  dqidi-statiis  :  surface 

I  Last  Qxnmaiid  to  Guidaiice :  inariL.oii_top 
I  eiiioute>wayp(Mt  :  4 


I  ObsMcles  I 


I  Direction  i  Proximity  (Type  t 

89.0  far  fkiating 

3S6.0  far  floating 


I  EQUIPMENT  DOWN 


«************4t4r********«««4>4>4'*«**4i*4>4>****4t***<l>* 

Event  Number:  16 

Description:  maric_on_aboit_waypcMnt 
Time  :  125.000 

•************«****4i«**********4i***«**4>******4t** 


»>»Made  it  to  Goal«<«« 

At  time :  125.0339999999997 

10135  rules  fired  Run  time  is  128.4349999999995  seconds 
78.91 151 165959467  rules  per  second 
22  mean  mmdter  oi  fKts  (30  maximum) 

2  mean  mmdter  oi  activations  (8  maximum) 

CLIPS>  (exit) 


3.  SCENARIO  3 


CLIPS>  (watch  statistics) 
CL]PS>  (batch  uploadbat) 
CLIPS>  (close) 

FALSE 

CLIPS>  (clear) 

CLIPS>  Goad  skipparxlp) 
CLIPS>  (load  maneuveringxlp) 
CLIPS>  (load  navigatKMixlp) 
CLIPS>  (load  sensorx^)) 
CLIPS>  (load  cnvironinaitclp) 
CLIPS>  (reset) 

CLIPS>  (run) 


Welcome  to  the  MISSION  EXEClTim  DEMO 

WAYPOINTS:  All  scenarios  take  place  over  the  same  set 
of  INITIAL  waypoint  cooniuiates. 

EQUIPMENT:  All  equipment  is  simulated  in  the  event  file 
Objects  are  creat^  for  each  onboard  equipment 

SITUATIONS:  All  situations  are  also  simulated  in  the  event 
file.  For  instance,  an  obstacle  detecdcm  is 
listed  and  this  simulates  the  CM>stacle  Avoidance 
DeciskmMaker  passing  this  information  through 
die  interface  to  the  Executor . 

SCENARIO  (CHOICES:  selea  number  <Ret> 

1  WaypoinL.Hqpping  Only  (transit) 

2  Obstacle  Avoidance 

3  Vehicle  Contnd  System  Failure 

4  Obstacles  and  Environment  Problems 

5  Equipment  Failures 

6  E]dt  the  Siimilamr 
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3 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  WaypointAiTival-DeptfiCoaqMuistm 
level  :  Lowjusessment 
action:  delennine_type_of_dq)th_change 
time  :  0^ 


»»»»»»  Decisicm  «««««« 
QTpe  :  Navigation 

rale  :  Waypoint_DistanceTiine_Qieck 
level  :  Low.assessment 
action:  detenmne_if_need_to_increase_speed 
dme  :  0.380 


»»»»»»  Decision  «««««« 

Qrpe  :  Navigation 

rale  :  Waypoint_monitor 

level  :  Low.assessmem 

action:  assess_next_waypoint_and_sequence 

time  :  0.543 


Skipper's  Di^lay  t 


TIME  inmin_secs  O.’OO 

Overall  Mission  Status  »»  Continue.Unrestricted  «« 
Manuevering_Status :  unrestricted 
Equ9ment_Status  :  normal 
Navigatkxu.Status  :  withinjolerance 
Eiivironment_status :  normal 
Spec.Misskm^status:  feasible 

levcriution  :  transit 
Idqrth-status  :  dive 
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I  Last  Command  to  Guidance :  underway 
I  enroute-waypoint  ;  1 


Obstacles  I 


I  Direction  I  Proximity  I  Type  I 


EQUIPMENT  DOWN  I 


Event  Number:  1 


Description :  passing_waypoint_l 


Time  10.000 

»»»»»»  Decision  «<««««< 
type  :  Navigation 

rale  :  WaypmntArrival-DepthComparison 
level  :  Low.assessment 
action :  dctermine_type_of_depth_changc 
time  :  10.246 


»»»»»»  Decision  «««««« 
Qfpe  :  Navigation 

rale  :  Waypoint_DistanceTime.Check 
level  :  Low.assessment 
action :  determine_if_need_to_increase_^)eed 
time  :  10.420 


»»»»»»  Decision  «««««« 

type  :  Navigation 

nile  :  Waypoint.monitcn- 

level  ;  Low.assessment 

action :  assess_next_waypoim_and_seqoence 

time  :  10.583 
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TIME  ininin_secs  0:10 

Ovenll  Mission  Status  »»  Condnue.Unrestricted  «« 
Manueveriiig_Statas :  unrestricted 
Equqmient_Status  :  nonnal 
N8vigarion_Status  :  within_tolenuice 
EnvironineniLStatus :  normal 
Spec_Mi8sion_status:  feasible 

- 1 

levcdution  :  transit 
I  depth-status  :  dive 

I  a88ag«gaa«KBae:i  i,.  Li',iiaaamis5;BaBBa88aaai— : - car  r-r' 

I  Last  Command  to  Guidance :  mark_(m_top 
I  enroute-waypoint  :  2 


Obstacles  I 


i  Direction  I  Proximity  I  Type  I 


I  EQUIPMENT  DOWN 


«*4i*****«**«i«i4i«*4i*4t4t****4i4i*4i4i4i***4i4t*4>4t*4i**4i4i4i4i* 

Event  Numbo*:  2 

Description :  passing_waypoint_2 

Hme  :  20.000 


»»»»»»  Decision  «««««« 
Qrpe  :  Navigation 

nde  :  WaypointAirival-DepthComparison 
level  :  Low_asaessment 
action:  detennine_type_of_depth_chan^ 
time  :  20.616 
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»»»»»»  Decisicm  «««««« 
type  :  Navigation 

rule  :  WaypointJ>istaiice'nine_Qieck 
level  :  Low_assessinent 
action:  detBraiine_if_need_.to_incfease_q)eed 
tune  :  20.793 


»»»»»»  Decision  «««««« 

type  :  Navigation 

rale  :  Waypoint_inonitor 

level  :  Low_assessment 

action:  a8sess.next_wayp(rint_and_sequence 

time  :  20.957 


I  Skipper's  Display  I 


TIME  iniiiin_secs  0:20 

Overall  Mission  Status  »»  Continue.Unrestricted  «« 
Manuevering_Status :  unrestricted 
EquqmieniLStatus  :  normal 
Navigation.Status  :  within_tolerance 
Envirmunent_status :  normal 
Spec_Mission_status:  feasible 

- 1 

levrtiution  :  transit 
I  dqKh-status  :  dive 

I  Last  Command  to  Guidance :  mark_on.top 
I  enroute-waypoint  :  3 


I  Obstacles  I 


I  Direction  I  Proximity  I  Type  I 


I  EQUIPMENTDOWN  I 
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Event  Number :  3 


Descrii>tk>n :  passing_wayp(mt_3 
Time  :  27.000 


»»»»»»  Decision  «««««« 
type  :  Navigition 

nik  :  WiypointAirival-Dq>diOooqMiison 
level  :  Lowjisiessment 
action:  deiennine_type_<<_dqMli_diange 
time  :  27^1 


»»»»»»  Decision  «««««« 
type  :  Navigaticm 

rule  :  WaypoinuDistanceTIme.Check 
level  :  Low_assessment 
action:  deiermine_if_need_tt>_inciease_speed 
time  :  27.383 


Skipper’s  Di^lay 


TIME  inmin_secs  0:27 

Overall  Mission  Status  »»  Continue.Unrestricted  «« 
Manuevering_Status :  unrestricted 
EqutyaKnt_Stattts  :  normal 
Navifation_Status  :  within_ttderance 
EnvironmeniLstatus :  nonnal 
Spec_Mis8ion_status:  feasible 


levtdution  :  transit 
IdqNh-stttus  :  dive 


I  Last  Command  to  Ouidanoe:  Increase-Speed 
I  enroute-wqrpmnt  :  3 
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I  Directioii  I  Proximity  I  Type  t 


I  EQUIPMENTDOWN  I 


»»»»»»  Decision  «««««« 

type  :  Navigation 

nde  :  Waypointjawnitor 

level  :  Low_assessinent 

action:  asaessjnext.waypoint_and_sequence 

time  :  28.122 


****4i**«**«**«*****4i**4i**4i*4i******4i*4i**4i*****4i* 

Ev«it Number:  4 


Description :  Plane_controls_failure 


Tune  :  35.000 

»»»»»»  Decision  «««««« 

type  :  Maneuvering 

rale  :  Maneuvering_Status_Assessment 

level  :  maneuvering-assessment 

action:  change-overall-maneuvoing-status 

time  :  35243 


»»»»»»  Decision  «««««« 
type  :  Systan_Monitor 

:  CratiDl_System_Failure 
level  :  Low 

action:  Pass.info_tD.^uip_Assessor 
time  :  35.409 


»»»»»»  Decision  «««««« 

type  :  System_Monitor 

rule  :  E^pmenuStatus.Assessment 

level  :  Assessment 

action:  Assessing_Status 
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tiine  :  3S.S71 


»»»»»»  Decision  «««««« 

Vfpt  :  OveraU_Mission 

rale  :  OvenU_Missi<Hi_Assessor 

level  :  High 

action:  Aborumission 

tune  :  35.740 


»»»»»»  Decision  «<«««<« 

Qfpe  :  OvenlLMisskxi 
rale  :  AlKXt.Mission 
level  :  Low 

action :  lock^status_and_rq)lan_route_to_idx)rt_rendezvous 
time  :  35.898 


»»>  Shutting  Down  for  Dynamic  Recovery  «< 

>»»  Tianqxmder  will  function  for  2  hours  <« 

2931  rales  fiml  Run  time  is  41.71299999999974  seccmds 
70.26586435883343  rales  per  second 
16  mean  number  of  funs  (27  inaxinium) 

2  mean  number  of  activations  (1 1  maximum) 

CL1PS>  (dribbleK^ 
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4.  SCENARIO  4 


CLIPS>  (watdi  statistics) 
CLIPS>  (baidi  iqdoad.bat) 
GLIPS>  (close) 

FALSE 
CLIPS>  (clear) 

CLIPS>  (load  skqiper.clp) 
CLIPS>  (load  iiiaiietivering.clp) 
CLIPS>  (load  iiavigation.clp) 
CL1PS>  (load  sensorxlp) 
CLIPS>  (load  envifonmenLc^)) 
CLIPS>  (reset) 

CLIPS>(run) 


Welcome  to  the  MISSION  EXECUTOR  DEMO 

WAYPOINTS:  All  scenarios  take  place  over  Ae  same  set 
of  INITIAL  waypoint  coordinates. 

EQUIPMENT:  All  equipment  is  simulated  in  the  event  file 
(X>jects  are  cieat^  for  each  onboard  equqmient 

SnUATTONS:  All  situations  are  also  simulated  in  the  event 
file.  For  instance,  an  obstacle  detection  is 
listed  and  this  simulates  the  Obstacle  Avoidance 
DeciskmMaker  passing  this  infonnation  duough 
die  interface  to  die  Executor . 

SCBNARK)  CHOICES:  select  number  <Ret> 

1  WaypoincHopping  Only  (transit) 

2  Obsude  Avokhuice 

3  VdddeCoatnd  System  Failure 

4  Obstacles  and  En^ionmentlVoblans 

5  Equ^ment  Failures 

6  Eidt  die  Sirnulamr 


4 


»»»»»»  DecisuMi «««««« 
type  :  Navigatiofi 

nde  :  WaypcmtAirival-DeptliCnnpirisoa 
level  :  Lowjusessment 
action:  detennine_type_of_dq>th_change 
tune  :  0.217 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  Waypoint_Distance*nnie_Check 
level  :  Low_assessment 
action:  deiennine_if_need_to_inciease_q)eed 
time  :  0.392 


»»»»»»  Decision  «««««« 

type  :  Navigation 

tide  :  Waypoint_monitor 

level  :  Low_assessnient 

action:  assess_next_wayp(Mnt_and_sequence 

time  :  0.5S7 


Skipper’s  Di^lay 


TIME  iniiiiu_secs  OKX) 

Overall  Mission  Status  »»  Continoe.UnreMricted  «« 
Manuevering^Status :  unrestricted 
Equq>ment_Status  :  normal 
NavigatiooLStatus  :  witlun_t(rietBnoe 
Eaviroiuneac.status :  nonnal 
Spec_Miraion_status:  feasiUe 

I  evolution  :  transit 
Idqidi-stttns  :  dive 

I  Last  Conmand  ID  Guidance:  undoway 
I  enroute-waypoint  :  1 
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I 


Obstacles 


I 


I  DirectitMi  I  Proximity  I  Type  I 


I  EQUIPMENT  DOWN 


Event  Number:  1 


Description:  passing_waypQint 


Time  10.000 

»»»»»»  Decision  «««««« 
9pe  :  Navigation 

rale  :  WaypomtAnival-DepthGmiparistxi 
level  :  Low_assessment 
action:  detennine_type_of_dq)th_change 
time  :  10.214 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  Waypomt.DistanceTlme.Check 
level  :  Low.assessment 
action:  deiermine_if_need_toJncrease_speed 
time  :  10.388 


»»»»»»  Decision  «««««« 
type  :  Navigation 
rale  :  Waypranumonitor 
<  level  :  Low.assessment 

action:  assess_next_waypointu.and_sequence 
«  time  :  10.S52 


I  Skipper’s  DispUy  I 
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TIME  in  nunusecs  0:10 

Ovofsll  Misnon  Status  »»  Gontinue.Unrestricted  «« 
Maniievcring_Status :  unrestricted 
EquqxnentJStatus  :  nonnal 
Navigation_Status  :  within_tcdeianoe 
Enviroiiiiient_status :  nonnal 
Spec_MissbnL.status:  feasible 

- 1 

levtriutkm  :  transit 
I  dqpdi-status  :  dive 

ILiotGoininand  to  Guidance:  inariL.on_top 
I  enroute-waypoint  :  2 


I  Obstacles  I 


I  Direction  I  Proximity  I  Type  I 


I  EQUIPMENTDOWN  i 


««***««***«*«««*****4i*4i**4i*4i*******«t*«**«*4i«*** 

Event  Number:  2 


Description:  obstacle.detected_at_normal_rBnge 
Time  :  27.000 


Event  Number:  3 


Description:  obstacle.classified_as_new 
lime  :  27.000 


4 


»»»»»»  Decision  «««««« 
type  :  Maneuvering 

rule  :  Obttacle_deiection_Nonnal_Umits 

level  :  Lofw_assessment 

action:  claMify_nonnal_nuige_obstacle_as_new 
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ipp 


gppfpippyv , 


tiine  :  27.428 


»»»»»»  Decision  «««««« 
type  :  Maneuvering 
rale  :  CoI]ective_Obstacle_Assessinent 
level  :  Low_assessment 

action :  assess_whetlier_presents_a_collision_danger_and_tum 
time  :  27.624 


****************«**************4i«************** 

Event  Number:  4 

Description :  obstacle_detected_at_nonnal_range 
Time  :  37.000 

****4i4i***4i4i*«4i4i4i*4t**4i4i**«*****4i4i*4i*********4i**« 

**4i4i****4i**4i*****4i4i4i*4i4i*«**4i4i4i*4i4i**<|i4i4i4i****4t*4i* 

Event  Number:  5 


DescriptitMi :  obstacle.detected.at.nonnaljrange 


Time  :  37.000 

«4t4>*4i*4t4i***4i**4i*4i*4i*4i4i*4t***4i4i****4i**4i4t«****4i4>*4> 

»»»»»»  Decision  «««««« 
type  :  Maneuvering 

rale  :  Obstacle.detection.Normal.Limits 
level  :  Low.assessment 
action :  classify_nomial_range_obstacle_as_new 
time  :  37.475 


************4i4i4>4i*4t**4i4i**«********«***4>****«i**** 

Event  Number:  6 


Descriptitm :  obstacle_classiEed_as_new 


Tune  :  40.000 
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4i4i4>******«*4i***4i**4i*4i4i***4i«4i*4i****4i*4i****4i*4i*** 


Event  Number :  7 


Description:  obstacle_update_previous_detect 


Hme  :  40.000 

4I********************************************** 

»»»»»»  Decisicm  «««««« 

9pe  :  Maneuvering 
niie  :  Obstacle.Update 
level  :  Low_assessiiient 

action :  update_obstacle_status3angebearing,cdlisi(m-danger 
time  :  40.843 


Evoit Number:  8 


Descripticm :  sea_temp_does_not.nnatch_exp_reading 


Time  :  30.000 

*«***«4i«*4i««4i***«4i*t|i4i*»*4t**«4i4t*4i**4i**4i**»«4i*4i** 

»»»»»»  Decision  «««««« 
type  :  Environmental_world 
rule  :  Environment_Assessor 
level  :  Assessment 

action :  deiennine_if_envinmment_status Js.hazard 
time  :  30.236 


Event  Number:  9 


Description:  pressore_out.of_limits 
Time  :  60.000 


»»»»»»  Decision  «««««« 
type  :  Environmental.world 
rale  :  Environmeni_Asscssor 
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levd  :  Assessment 

action:  detennine_if_envinMmiait_statusJs_hazanl 
time  :  60.750 


************4i***4i***********4i*********4t4t******* 

Event  Number:  10 


Description:  gyiD_indicates_abn(HTnal_setL.turbulence 


Hme  :  65.000 

***********4i****4t**4i*******«4i**«***********4t*** 

»»»»»»  Decisitm  «««««« 
type  :  Environmental.world 
rule  :  Environment_Assessor 
level  :  Assessment 

action :  detBiniine_if_enviioninent_status_is_hazard 
time  :  65.244 


»»»»»»  Decision  «««««« 

type  :  Overall^Mission 

rule  :  Overall_Mission_Assessor 

level  :  High 

action:  Abort_mission 

time  :  65.41 1 


»»»»»»  Decisicm  «««««« 
type  :  Overall.Mission 
nile  :  Abort.Mission 
level  :  Low 

acticm :  lock_status_and_feplan_route_to_abQrt_rendezvous 
time  :  65.569 


»»»»»»  Decisitm  «««««« 
type  :  Navigation 

rule  :  WaypomtAnival-DepthComparison 
level  :  Low_assessment 
action :  determine_type_of_depth_change 
6me  :  65.867 


193 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  Wayp(^t_PistanceTime_Check 
level  :  Low.assessment 
action:  deteraiine_if_need_to_increase_S9)eed 
time  :  66.040 


»»»»»»  DecisicMi «««««« 

type  :  Navigation 

rale  :  Waypoint_iiionitor 

level  :  Low_assessiiient 

action :  assess_next_waypoint_and_sequence 

time  :  66.203 


Skipper's  Display  I 


TIME  inmin_secs  1:05 
Overall  Mission  Status  »»  Abort_missi<m  «« 
Manuevering_Status :  unrestricted 
Equqnnent_Status  :  normal 
Navigation.Status  :  within.tolerance 
Environment_status :  major.deviation 
Spec_Mission_status:  feasible 

- 1 

■  evolution  :  abcnt.transit 
I  depth-status  :  no-depth-change 
1^--^ - 

I  Last  Command  to  Guidance :  transiting_to_abort_rendezv(His 
I  emoute-waypoint  :  1 


Obstacles  I 

I  Direction  I  Proximity  I  Type  I 

82.0  far  floating 

356.0  far  floating 
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I  EQUIPMENT  DOWN 


I 


»»»»  SeaTeinpSensor«««« 

»»»»  SeaStat^yro«««« 

»»»»  I¥essureTransdiicer«««« 

****«i**4i4i4i*«4i*4i4i4i4<4i4i>|i4i**4i4>4i4i****4i*******4i*4i**4i* 

Event  Number:  11 


Description:  passing_waypoint 


Hme  :  95.000 

4i**4i«*«4i4i*4i«****4i4i***4i«4i«4i**4i***4i***4i***4i***4i** 

»»»»»»  Decision  «««««« 

:  Navigaticm 

rule  :  WaypointAnival-DepthG)mparison 
level  :  Low.assessment 
acticm :  deterniine_type_of_depth_change 
time  :  95.225 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  WaypoincDistanceHme^Check 
level  :  Low.assessment 
action :  detefmine_iCneed_to_increase_spee(l 
time  :  95.399 


»»»»»»  Decision  «««««« 
type  :  Navigation 
rale  :  Waypoint_monitor 
level  :  Low.assessment 
action :  assess_next_waypoint_and_sequence 
time  :  95.565 


I  Skipper’s  Display  I 


TIME  inmm_secs  1:35 

Overall  Mission  Status  »»  Abort_mission  «« 

Manuevering_Status :  unrestricted 
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EquqmienL.Status  :  normal 
NavigBtion_Statas  :  within_tolerance 
Enviroament.status :  major.deviaticm 
Spec_Mission_status:  feasible 

- 1 

levrdutkm  :  aborL.transit 
I  depth-status  :  ascent 

I 

I  Last  Command  to  Guidance :  underway 
I  eniDute-waypoint  :  2 

I  Obstacles  I 


I  Direction  I  Proximity  ITVpe  I 

82.0  far  floating 

356.0  far  floating 


I  EQUIPMENT  DOWN 


»»»»  SeaTempSensor«««« 

»»»»  SeaStateGyro«««« 

»»»»  PtessureTransducer«««« 

*************4i****4i4>«i********4i**4i****4i**4t4i*4i*** 

Event  Number :  12 


Description:  passing_waypoint 


Time  :  115.000 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  WaypointAirival-DqithCompariscm 
level  :  Low_asaessment 
action:  determine.type.of.depth.change 
time  :  115.240 
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»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  Waypoint_Distance*nine_Qieck 
level  :  Low^assessnoent 
action:  d^eniiine_if_need_to_increase_speed 
time  :  11S.417 


»»»»»»  Decision  «««««« 

type  :  Navigation 

rale  :  Wayptrintjmonitor 

level  :  Low_assessment 

action:  assess_next_waypoint.and_sequence 

time  :  115.582 


1  Skipper's  Display  I 


TIME  inmin.secs  1:55 
Overall  Mission  Status  »»  Abort.mission  «« 
Manueveting_Status :  unrestricted 
Equipment_Status  :  normal 
Navigation.Status  :  within^tolerance 
Envitonment_status :  major_deviati(Mi 
Spec_Mission_status:  feasible 

■  evolution  :  abort_transit 

I  dqjth’Status  :  ascent 

I  - ^ - , - «=======-  r - 

I  Last  Command  to  Guidance:  maik_on_tq) 

I  enroute-waypoint  :  3 


Obstacles 


I 


I  Direction  I  Proximity  I  Type  I 

82.0  far  floating 

356.0  far  floating 


I  EQUIPMENT  DOWN  I 
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»»»»  SeaTeinpSensor«««« 

»»»»  SeaStat^yio«««« 

»»»»  PressureTrBnsducer«««« 

******«*4i***4t**4><i4i*****4i*4t****4i4i4i4i*****4i******* 

Event  Number ;  13 


Description:  passing_waypoint 


Tiiiie  :  126.000 

******4i***********«*4i*4i***4i4>4i*******4t********** 

»»»»»»  Decision  «««««« 
type  :  Navigation 

nile  :  WaypointAirival-DepthComparison 
level  :  Low.assessment 
action:  determine_typejofjdepth_change 
time  :  126.214 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rule  :  WaypointJDistance*nnie_Qieck 
level  :  Low.assessment 
action :  detBrniine_if_need_to Jncrease_speed 
time  :  126.392 


»»»»»»  Decision  «««««« 

type  :  Navigation 

rule  :  Waypoint.monitor 

level  :  Low.assessment 

action :  assess_next_waypoint.and_sequence 

time  :  126.557 


Skipper's  Display  I 


TIME  inmin_secs  2:06 
Overall  Mission  Status  »»  Abort.mission  «« 
Manuevering_Status :  unrestricted 
Equ4xnent_Status  :  normal 
Navigation.Status  :  within_Ktierance 


198 


Envinmiiieiiustatiis :  inajor_deviati<xi 
Spec_Mission_status:  feasible 


I 


levdutkm  :  aboit_transit 
I  depth-status  :  surface 

I  ■  . . .  ■  . . . 

I  Last  Command  u>  Guidance :  maric.cm.tq) 
I  enioute-waypoint  :  4 


I  Obstacles  I 


I  Direction  I  Proximity  I  Type  I 


82.0  far  floating 

356.0  far  floating 


I  EQUIPMENT  DOWN 


»»»»  SeaTen^ensor«««« 

»»»»  SeaStateGyro«««« 

»»»»  ftessureTransducer«««« 

*«*****4i****4t4i**«*«*4t4>4i4i4<4i**4t**4r*4>4t4i4i4i4r4t4i*4r4t4i«* 

Event  Number:  14 


Description :  Goal.airival 


Time  :  148.000 


>»»Madc  it  to  Goal«««< 

At  time :  148.0519999999997 

13301  rules  fired  Run  time  is  150.860999999999  seconds 
*  88. 16725329939541  rules  per  second 

20  mean  number  facts  (27  maximum) 

>  2  mean  number  of  activations  (7  maximum) 

CLIPS>  (dribble-off) 
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5.  SCENARIO  5 


C1JPS>  (watdi  statistics) 
CL1PS>  (batdi  uirfoadbat) 
CLIPS>  (ckMc) 

FALSE 
CLIPS>  (clear) 

CLIPS>  (load  skq)per.c^) 
CLIPS>  (load  inaiieiiveiing.clp) 
DC1JPS>  (load  navigation.clp) 
DCL1PS>  (load  sensorx^) 
CLIPS>  (load  environmaiLc^) 

j 

CLIPS>  (reset) 

CLIPS>(nin) 


Welcome  lo  the  MISSION  EXECUTOR  DEMO 

WAYPOINTS:  All  scenarios  take  place  over  die  same  set 
of  INITIAL  waypoint  ooonfinates. 

EQUIPMENT:  All  equiproent  is  siniiilated  in  the  event  file 
Otgects  are  creat^  for  each  onboard  equqmient 

SITUATIONS:  All  situations  are  also  simulated  in  die  event 
file.  Fbr  instance,  an  obstacle  detection  is 
lisied  and  dus  simulates  the  Obstacle  Avoidance 
DecisionMalEer  passing  this  information  diroogh 
the  interfiree  to  the  Executor . 

SCENARK)  CHOICES:  select  number  <Ret> 

1  Wqfpoim_Ho|iping  Only  (transit) 

2  Obittde  Avoidmce 

3  VeUde  Coittiol  Syflem  Fulnre 

4  Obstades  and  Environment  FroMems 

5  Eqaipiiient  Failures 
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6  Exit  the  Simulator 


5 


»»»»»»  Dedskm  ««<«««< 
type  :  Navigation 

nde  :  WaypointAnival-DepthQmpaiison 
level  :  Low_asaessment 
action:  detennine_type_of_dq)th_.change 
time  :  0.202 


»»»»»»  Decision  «««««« 
type  :  Navigation 

nile  :  WaypdncDutanceHine.Check 
level  :  Low_asaessment 
action:  detennine_if_nee(Lto_increase_speed 
time  :  0.376 


»»»»»»  Decision  «««««« 

type  :  Navigation 

rale  :  WaypoiniLmoniior 

level  :  Low_assessment 

action:  assess.nexL.waypoint_andLaequence 

time  :  0.539 


4 


) 


Skipper's  IXq>lay 


TIME  inminL.secs  OKX) 

Overall  Missioo  Status  »»  Gontinue.Unrestiicted  «« 
Manueveting_Status :  unrestricted 
Equ^mencStatus  :  normal 
Navigation_Status  :  within_toleiinoe 
Environment_8tttus :  normal 
Spec_MiasiooLftatus:  feasiUe 
- 1 


I  evttiution  :  transit 
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I  dqpdi-statnt  :  dive 


i  Last  Comnuuid  to  Guidanoe :  imdenwiy 
I  earome-waypoiiit  :  1 


Obstacles 


I  Direction  I  Rtoximity  liype 


EQUIPMENT  DOWN 


Event  Number :  1 


Descriptkm:  passing_waypQint_l 
Time  :  10.000 


»»»»»»  Decision  «««««« 
type  :  Navigation 

nile  :  WaypointAnival-DqidiOomparison 
level  :  Low_asaessmem 
action :  determine jtypejofjdepdijdiange 
time  :  10.216 


»»»»»»  Decision  «««««« 
Qrpe  :  Navigation 

nile  :  WaypointJDistanceTime.Clieck 
level  ;  Low_assessment 
action:  determine JfjneedLioJncreaae_q)eed 
time  ;  10.390 


»»»»»»  Decision  «««««« 

type  :  Navigation 

rale  :  Waypointjnonitar 

level  :  Loiw_asaessment 

action:  assess jiexL.waypoint^and,_seqiienoe 

time  :  10.553 
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I 


Skipper’s  Diq>lay 


I 


TIME  inmin^secs  (hlO 

OvobU  Missi(»  Status  »»  Continue.Unrestricted  «« 
Manuevering_Status :  unrestricted 
Equipment_Status  :  normal 
Navigation_Status  :  within.toloanoe 
Environmentjstatus :  normal 
Spec_Mission_status:  feasible 

- 1 

I  evtdution  :  transit 
I  depth-status  :  dive 

I  Last  Command  to  Guidance :  maik_on_top 
I  emoute-waypcrat  :  2 


I  Obstacles  I 


I  Direction  I  Proximity  I  Type  I 


I  EQUIPMENT  DOWN  I 


Event  Number:  2 


Description:  passing_waypoint_2 
Hme  :  20.000 


»»»»»»  Decision  «««««« 
type  :  Navigation 

nik  :  WaypointAfiival-DqxhCompaiison 
level  :  Low_assessment 
action:  determine.^pe.oLdepth.change 
dme  :  20.634 
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»»»»»»  Decisi(m  «««««« 
type  :  Navigatum 

riiie  :  WaypointJ>i8tancell]iie_Check 
level  :  Low.assessmem 
action:  detBnmne_if_need_toJinciea8e_8peed 
time  :  20.811 


»>»»»>»  Dedsion  «««««« 

type  :  Navigation 

nde  :  WaypoiniLinonitar 

level  :  Low_a8se8sment 

action:  a88ess_next_waypoint_and_sequence 

time  :  20.975 


Skipper's  Display  I 


TIME  inmin_secs  0:20 

Overall  Mission  Status  »»  Continue_Untestricted  «« 
Manuevering_Status :  unrestricted 
Equipment_Status  :  nonnal 
Navigation_Status  :  witliin_tolerance 
Environment_status :  normal 
Spec_Mission_status:  feasible 

- 1 

I  evolution  ;  transit 
I  depth-status  :  dive 

.  r-^  . . . 

I  Last  Command  to  Guidance :  mariL.on_top 
I  enroote-wayptmt  :  3 


Obstacles  I 

I  Direction  i  PANumity  I  Type  I 


I  EQUIPMENTDOWN  I 
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Lil4,.piLp|Jl.iiP|||pppi^^ 


Evoit  Numbo’ :  3 


Description:  passing_waypQint_3 


Tune  :  27.000 


»»»»»»  Decision  «««««« 
type  :  Navigation 

niJe  :  WaypomtAirival'DqMhCompariscm 
fevel  :  Low_asaessnient 
action:  detBnnine_type.<rfLdepth_change 
time  :  27.209 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rale  :  WaypomtJDistanceHme.Check 
level  :  Low.assessment 
action :  detBnnine_if_need_to_inciease_sp6ed 
time  :  27.389 


I  Skipper's  Display  I 


TIME  inntin_secs  0:27 

Overall  Mission  Status  »»  Continue.Unrestricted  «« 
Manuevering_Status :  unrestricted 
EquipmencStatus  :  normal 
Navigation_Status  :  within_tolerance 
Environment_status :  normal 
Spec_Mission.status:  feasible 

- 1 

I  evttiution  :  transit 
I  depth-status  :  dive 

I  Last  Command  to  Guidance :  Increase-Speed 
I  emonte-waypoint  :  3 


I  Obstacles  I 

I  Infection  I  Plradmity  iiype  I 


I  EQUIFMENTDOWN  I 


»»»»»»  Decision  «««««« 

type  :  Navigation 

nde  :  WaypoinL.nionitor 

fevel  :  Low_assessnient 

action.:  assess_nextLwaypQinL.and_8equence 

time  :  28.129 


Event  Number:  4 


Description:  sonar_has-£silure-ieading 
Time  :  35.000 


»»»»»»  Decision  «««««« 
type  :  System^Monitor 
nile  :  Sonaxipailure 
kvel  :  Low 

action:  Pus_info..to_Equip_Assess(ir 
time  :  35.300 


»»»»»»  Decision  «««««« 
type  :  System_Moniior 
rale  :  Equi|Rnent^Status_Asaessment 
level  :  Assnsment 
action:  Assnsing^Status 
time  :  35.463 


»»»»»»  Decision  «««««« 
type  :  OveralLbffisrion 
role  :  OvoalLNQssionLAssessor 
level  : 

action:  GbotiniieMiasion^widi.jestrictions 
time  :  35.630 
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»»»»»»  Decision  «««««« 

type  :  Overall_Mission 

rale  :  Continue_niissi(Mi_restiicted_initial 

level  :  Assessment 

action:  Note-time-of-status-change 

time  :  35.791 


*^^0m******************************************0 

Event  Number:  S 
Description:  passing_waypoint_4 
Tune  :  55.000 

0*m*ttt***************************m************** 


»»»»»»  Decision  «««««« 
type  :  Navigation 

Pile  :  WaypointArrival-DepthComparison 
level  :  Low.assessment 
action:  determine_type_of_depth_change 
time  :  55.236 


»»»»»»  Decision  «««««« 
type  :  Navigation 

rule  :  Wayp(mtJ>istance’nme_Check 
level  :  Low.assessment 
action:  deteimine_if_need_to_inaease_speed 
time  :  55.419 


I  Skipper's  Display  I 


TIME  inmin_secs  0:55 

Overall  Mission  Status  »»  Continue_with_Restricti(His  «« 
Manuevering_Status :  unrestricted 
Equi|nnent_Status  :  equipment_critical 
NavigatioiuStatus  :  with^_tdenuice 
Environment_status :  normal 
Spec_Mission_status:  feasible 
- 1 


i  evolutkm  :  transit 


I  depth-status  :  no-depth-change 

In-.^-rT.- -  r-r  . - 

I  Last  Command  to  Guidance :  Increase-Speed 
I  emoute-waypoint  :  4 


I  Obstacles  I 


I  Direction  I  Proximity  I  Type  I 


I  EQUIPMENTDOWN  I 


»»»»  FWD-saiar«««« 

»»»»»»  Decision  «««««« 

type  :  Navigadtm 

rule  :  Wayp(nnt_monitor 

level  :  Low.assessment 

actiem :  assess_next_waypoinuand_sequence 

time  :  56.202 


**«********4i*4i*«**4>4i******4i***«**«*«i«*****«*4t4i* 

Event  Number:  6 

Desci4>tion:  sonar_has_failure-reading 
Hme  :  65.000 


»»»»»»  Decision  «««««« 
type  :  Sy8tem_Monitor 
rule  :  Sonar.Critical 
level  :  low 

action:  PassJnfo_lD_Equip_Assessor 
time  :  65.265 


»»»»»»  Decision  «««««« 

type  :  System^onitor 

tide  :  EquipmenL.Status_Assessment 

level  :  Assessmmit 

action:  Assessing.Status 
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time  :  65.426 


»»»»»»  Decision  «<««««< 
typt  :  Overall_Mission 
nde  :  Ovaall_Missi(Mi_Assessor 
level  :  High 

action:  ContinueMissi<m_witii_iestrictions 
time  :  6SJ96 


»»»»»»  Decision  «««««« 

type  :  OvmalLMission 

rale  :  Continue_mi8sionjtestrictBd_initiaI 

level  :  Assessment 

action:  Note-time-of-status-change 

time  :  65.754 


4i«i4i**4i4>«4i4i*****4i4i«4i*«****4i***««*4i*«******«i***** 

Event  Number:  7 


Description:  rudder Jhasjfailurejteading 
Tune  :  68.000 


»»»»»»  Decision  «««««« 
type  :  Maneuvering 
rule  :  Maneuvering_Status_Assessment 
level  :  maneuvering-assessment 
action:  change-overall-maneuvering-status 
time  :  68.303 


»»»»»»  Decision  «««««« 

type  :  Overall_Missioa 

rule  :  OveraU_Mission_Asaessar 

level  :  High 

ac^»:  Abort_misaon 

time  :  68.470 
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»»»»»»  Decision  «««««« 

:  OvenU_Mission 
role  :  Aboct_Misskm 
level  :  Low 

action:  lock_status_andjtiq)i!an_route_to_aboft_iendezvous 
time  :  68.633 


»»>  Shutting  Down  for  Dynamic  Recoveiy  «< 

»»>  Transponder  will  function  for  2  hours  «< 

5761  rules  fired  Run  time  is  72  J0900000000074  seconds 

79.78229860543618  rules  per  second 
18  mean  number  of  Cicts  (29  maximum) 

2  mean  number  ai  activations  (12  maximum) 

CLIPS>  (dribble-off) 
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INITIAL  DISTRIBUnON  LIST 


i 

% 


1.  .Defense  Technical  Infonnadon  Center 
Camerni  Statitm 

Alexandria,  Virginia  22304-6145 

2.  Dudley  Knox  Ulnary 
Code  052 

Naval  Postgraduate  School 
Monterey,  California  93943-5002 

3.  Chairman,  Code  CS 
Department  of  Computer  Science 
Naval  Postgraduate  School 
Monterey,  California  93S143-5002 

4.  Dr.  Y.  Lee,  Code  CS/Le 
Department  of  Omiputer  Science 
Naval  Postgraduate  School 
Monterey,  California  93943-5002 


No  of  Conies 
2 


2 


2 


7 


5.  Chairman,  Code  69  Hy  1 

Department  of  Mechanical  Engineering 

Naval  Postgraduate  School 
Monterey,  California  93943-5002 

6,  LT  W.  P.  Wilkinson,  USN  2 

Departmmit  Ifead  Qass  121 

Surface  Warfue  OfRcCT  School  Command 
>  NETC  Newport,  Rhode  Island  02841-5012 

I 
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